Repository navigation
PackageManagment binaries should be installed under \Modules\PackageManagement\ folder #2347
Description
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
- Install https://github.com/PowerShell/PowerShell/releases/download/v6.0.0-alpha.10/PowerShell_6.0.0.10-alpha.10-win10-x64.msi
- 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. - ipmo "C:\Program Files\PowerShell\6.0.0.10\Modules\PackageManagement\Microsoft.PackageManagement.dll"
- 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
Activity
kilasuit commentedon Sep 23, 2016
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.
daxian-dbw commentedon Sep 23, 2016
This happens because when running
Import-Module <path-to-foo.dll>, powershell first tries to load the assembly using its short namefooviaAssembly.Load, and if that fails, it turns toLoadFromwith 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'edfoo.dllif there is one:For CoreCLR powershell,
Import-Module <path-to-foo.dll>would load thefoo.dllfrom$PSHomeif there is one there, which is the described symptom in this issue.daxian-dbw commentedon Sep 23, 2016
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
PackageManagementassemblies should be placed within the module folder, at least when we package and release powershell core.kilasuit commentedon Sep 24, 2016
see #2350 which also has this similar issue and would correct this too
HemantMahawar commentedon Oct 28, 2016
This issue was moved to PowerShell/PowerShellGet#41
jianyunt commentedon Oct 28, 2016
can you help me understand why this is OneGet issue? If PowerShellCore can not change the behavior by loading the binaries from root, even if a user explicitly ask from other folder, "ipmo C:\Program Files\PowerShell\6.0.0.10\Modules\PackageManagement\Microsoft.PackageManagement.dll" for example, then at least should package them to Modules folder so modules are updatable. In this case, put them under \Modules\PackageManagement folder. Reopen it.
kilasuit commentedon Dec 1, 2016
This seems to have been resolved in 6.0.0.13 with the binaries for PackageManagement being located correctly in
C:\Program Files\PowerShell\6.0.0.13\Modules\PackageManagement\1.1.1.0\coreclrHemantMahawar commentedon Dec 6, 2016
Ryan Yates (@kilasuit) Thanks for the confirmation.