Open TylerLeonhardt opened 7 years ago
@bmanikm also mentioned 1.1.3 works in this setup, but I was unable to verify. Copying 1.1.3 into the PackageManagement folder results in the same error.
The problem is that the old assemblies (Microsoft.PackageManagement.dll, etc.) were not deleted. Hence, the old dll was loaded which uses a different contract than the newer PSGet. Properly cleaning the folder resolved the above issue.
Save-Module seems to have an issue though:
Package is saved or a real error is shown
WARNING: The property 'AdministratorRightsNeededOrSpecifyCurrentUserScope' cannot be found on this object. Verify that
the property exists.
PackageManagement\Save-Package : Unable to save the module 'PackageManagement'.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\PSModule.psm1:1616 char:21
@brywang-msft
@tylerl0706 Please enhance the instructions for copying the PowerShellGet and PackageManagement folder contents with following details: (https://github.com/PowerShell/PowerShell-Docs/blob/85b17f0ff05558192bbb19bf6a7bd072ea809ea8/gallery/psget/get_psget_module.md#for-systems-running-powershell-3-or-powershell-4-that-have-installed-the-packagemanagement-msi)
@brywang-msft, I am fine with your proposal. When you say old Microsoft.PackageManagement.dll, do you mean even a user relaunches a new powershell console we are still loading the old .dll? @ bmanikm, changing assembly loading order will be bit tricky. I recommend we treat it separately from this issue. From the code, I can see If NuGet exists under providerassemblies folder, it gets load first. This is because NuGet provider was designed to work as bootstrap-able for fullclr or nano. Only the recent releases we packaged it as part of PM. Changing this will require a lot testing.
This change will impact less areas: Possibly we can ignore the nuget provider under providerassemblies if the Nuget provider exists under PackageManagement folder and the version is higher than one under providerassemblies in LoadProviders()
The problem is Microsoft.PackageManagement.dll (and possibly meta provider), not NuGet provider. NuGet 208 or 209 both work. No change required to how we deal with the ProviderAssemblies folder.
ok then the fix is simple. We can change the assembly loading order in the PackageManagment.psm1 to load the fullclr/coreclr first. if it does not exist, load the top level folder.
I'm receiving the following error when doing:
Find-Module azure
And just
Find-Module
gives me the "SoftwareIdentity" warning.OneGet 1.1.4 is not working on WS2012 R2. But it works on WIn10 and Server 16