PackageManagment binaries should be installed under \Modules\PackageManagement\ folder

[HemantMahawar]

From @HemantMahawar on October 28, 2016 20:38

From @jianyunt on September 22, 2016 23:49

Problem

It is observed that PowerShell core is loading assembles from its installed folder first (e.g. PowerShell\6.0.0.10) if exists, even if ipmo with a full path. For most cases, this behavior seems to be ok. However for the PackageManagement, we need to allow users to update the PackageManagement via install-module. The updated binaries will be installed under PowerShell\6.0.0.10\Modules\PackageManagement. But these updated assemblies won't get loaded because PowerShell loads the built-in PackageManagement assemblies first.

Proposed Solution

When packaging the next alpha release, PackageManagment binaries should be installed under PowerShell\6.0.0.10\Modules\PackageManagement\ folder instead of root PowerShell\6.0.0.10\ folder.

FYI: OneGet assemblies including .dlls/.ni.dlls:

Microsoft.PackageManagement.ArchiverProviders Microsoft.PackageManagement.CoreProviders Microsoft.PackageManagement Microsoft.PackageManagement.MetaProvider.PowerShell Microsoft.PackageManagement.NuGetProvider Microsoft.PowerShell.PackageManagement

Steps to reproduce

1. Install https://github.com/PowerShell/PowerShell/releases/download/v6.0.0-alpha.10/PowerShell_6.0.0.10-alpha.10-win10-x64.msi
2. copy any binary , In my case, Microsoft.PackageManagement.dll, to C:\Program Files\PowerShell\6.0.0.10\Modules\PackageManagement or any folder such as C:\Program Files\PowerShell\6.0.0.10\Temp.
3. ipmo "C:\Program Files\PowerShell\6.0.0.10\Modules\PackageManagement\Microsoft.PackageManagement.dll"
4. You will see the C:\Program Files\PowerShell\6.0.0.10\Microsoft.PackageManagement.dll is imported.

   Expected behavior

The assembly under C:\Program Files\PowerShell\6.0.0.10\Modules\PackageManagement\ should be loaded.

Actual behavior

Any assembly if exists under C:\Program Files\PowerShell\6.0.0.10\, will get loaded first.

Environment data

PS C:\Program Files\PowerShell\6.0.0.10> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.0.0-alpha
WSManStackVersion              3.0
GitCommitId                    v6.0.0-alpha.10
CLRVersion
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
BuildVersion                   3.0.0.0
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSEdition                      Core

Copied from original issue: PowerShell/PowerShell#2347

Copied from original issue: PowerShell/PowerShellGet#41

[HemantMahawar]

From @kilasuit on September 23, 2016 0:55

This looks like it is the same for the other modules that are installed with v6.0.0.10 too so would need to be resolved for them as well.

[HemantMahawar]

From @daxian-dbw on September 23, 2016 19:15

This happens because when running Import-Module <path-to-foo.dll>, powershell first tries to load the assembly using its short name foo via Assembly.Load, and if that fails, it turns to LoadFrom with the file path (https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/engine/ExecutionContext.cs#L1376).

Therefore, for FullCLR powershell, Import-Module <path-to-foo.dll> would load the GAC'ed foo.dll if there is one:

PS:1> Import-Module F:\temp\Microsoft.PowerShell.Commands.Diagnostics.dll
PS:2> $m = Get-Module "Microsoft.PowerShell.Commands.Diagnostics"
PS:3> $m.ImplementingAssembly.Location
C:\windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.PowerShell.Commands.Diagnostics\v4.0_3.0.0.0__31bf3856ad364e35\Microsoft.PowerShell.Commands.Diagnostics.dll

For CoreCLR powershell, Import-Module <path-to-foo.dll> would load the foo.dll from $PSHome if there is one there, which is the described symptom in this issue.

[HemantMahawar]

From @daxian-dbw on September 23, 2016 19:21

At any rate, if we want any in-box module to be update-able, then it should not leave the original set of assemblies around after it's updated. So PackageManagement assemblies should be placed within the module folder, at least when we package and release powershell core.

[HemantMahawar]

From @kilasuit on September 24, 2016 13:45

see #2350 which also has this similar issue and would correct this too

At any rate, if we want any in-box module to be update-able, then it should not leave the original set of assemblies around after it's updated.

[jianyunt]

This is PowerShellCore issue. Reopen it in PowerShellCore github.

[HemantMahawar]

PowerShellCore issue PowerShell/PowerShell#2347

[jianyunt]

ok . thx