Repository navigation
PackageManagment binaries should be installed under \Modules\PackageManagement\ folder #2347
Description
Activity
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.
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: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.dllFor 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.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.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.
This issue was moved to PowerShell/PowerShellGet#41
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.
- added this to the milestone
on Nov 2, 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\coreclrRyan Yates (@kilasuit) Thanks for the confirmation.
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
or any folder such as C:\Program Files\PowerShell\6.0.0.10\Temp.
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