Repository navigation
Closed
Labels
Issue-BugIssue has been identified as a bug in the productIssue has been identified as a bug in the productResolution-FixedThe issue is fixed.The issue is fixed.WG-Enginecore PowerShell engine, interpreter, and runtimecore PowerShell engine, interpreter, and runtime
Description
When there is an apostrophe in the filepath to a module Import-Module will work with modules that only have functions in however will fail if there is a class in the module. The exact same code will work when the module is located on a different path.
This situation was encountered due to the default OneDrive for Business path including an apostrophe. When using the user windowspowershell module with folder redirection all use modules now have an apostrophe in the path.
This affects both Version 5.1 and Version 6beta3
Steps to reproduce
Create Folder C:\Te'mp
Save the below code to C:\Te'mp\TypeName.psm1
# Define a class
class TypeName
{
# Property with validate set
[ValidateSet("val1", "Val2")]
[string] $P1
# Constructor
TypeName ([string] $s)
{
$this.P1 = $s
}
}
Import-Module 'C:\te''mp\TypeName.psm1'
Expected behavior
Module Loaded Successfully / No Output
Actual behavior
Import-Module : The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047)
At line:1 char:1
+ Import-Module 'C:\Te''mp\TypeName.psm1'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Import-Module], FileLoadException
+ FullyQualifiedErrorId : System.IO.FileLoadException,Microsoft.PowerShell.Commands.ImportModuleCommand
Environment data
> $PSVersionTable
Name Value
---- -----
PSVersion 6.0.0-beta
PSEdition Core
GitCommitId v6.0.0-beta.3
OS Microsoft Windows 10.0.14393
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Name Value
---- -----
PSVersion 5.1.15063.413
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.15063.413
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1Metadata
Metadata
Assignees
Labels
Issue-BugIssue has been identified as a bug in the productIssue has been identified as a bug in the productResolution-FixedThe issue is fixed.The issue is fixed.WG-Enginecore PowerShell engine, interpreter, and runtimecore PowerShell engine, interpreter, and runtime
Activity
iSazonov commentedon Jul 7, 2017
Leo D'Arcy (@ld0614) Thanks for your report!
Related PR #4136 - it seems we need full review allowed chars for "file names" vs "assembly names".
ld0614 commentedon Jul 7, 2017
I've written a (very quick and VERY dirty) script which loops through all visible ASCII chars and outputs the ones that fail. In version 5.1 the following fail: 39 ('), 44 (,) and 61 (=). Interestingly enough testing with version 6.0 Beta 3 the same 3 fail as well as 126 (~)
iSazonov commentedon Jul 8, 2017
This can vary on different platforms. We need more predictable way. I tried to find root code in CoreCLR repo. It seems the exception is here and failed code is here but I was not able to take the next step 😕
TimCurwick commentedon Jul 13, 2017
Whether or not this eventually gets fixed at the .Net level, I presume we want to add the work arounds in the PowerShell code in the meantime.
I can add three more Replace methods to the one that was merged last week for the comma.
We can use ’, [char]0x2019, the right quotation mark, to replace the apostrophe.
We can use ∼, [char]0x223C, the tilde operator, to replace the tilde.
The equals sign is not as straightforward.
=, [char]0xFF1D, the full width equals sign, as the only character I can find that looks like an equals sign is the most likely choice. The downside is that it is very wide, with whitespace built in, making it wider than standard ASCII characters, which throws off the spacing in plain text, which is probably no big deal but feels weird.
≃, [char]0x2248; ≐, [char]0x2250; and ≕, [char]0x2255 are close, but not quite matches for an equals sign. They, too, are wider than standard ASCII characters by varying amounts, but not as wide as the full width equals sign.
≈, [char]0x2243, is the right width, but it looks the least like an equals sign of the alternatives, and mathematically has a different meaning than an equals sign (almost or approximately equals). (The above three alternatives also have different meanings, but are less common so fewer people would be bothered by their mathematical differences.)
rkeithhill commentedon Jul 14, 2017
And don't forget that you can now use the Unicode esc sequence in dq strings e.g.
"`u{2019}". :-)donlassini commentedon Nov 26, 2017
This can also be reproduced in a simpler set up:
Save the TypeName.psm1 file as TypeName.ps1 and execute that.
You will get an error if e.g. the path contains a comma.
lzybkr commentedon Nov 26, 2017
DonLassini (@donlassini) - this bug was fixed in 71d5439 - are you still seeing the problem in the latest build?
iSazonov commentedon Nov 27, 2017
I can confirm that we can import module with apostrophe in the file path in latest builds.