search

OneGet / oneget

PackageManagement (aka OneGet) is a package manager for Windows
MIT License
2.38k stars 190 forks source link

OneGet 1.1.4 module not working on WS2012 R2 - Cannot find an overload for "SoftwareIdentity" and the argument count: "17" #289

Open TylerLeonhardt opened 7 years ago

TylerLeonhardt commented 7 years ago

I'm receiving the following error when doing:

Find-Module azure

WARNING: Cannot find an overload for "SoftwareIdentity" and the argument count: "17"
PackageManagement\Find-Package : No match was found for the specified search criteria and module name 'azure'.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\PSModule.psm1:1415 char:3
+          PackageManagement\Find-Package @PSBoundParameters | Microsoft.PowerShell.Core\ ...
+          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          + CategoryInfo                      : ObjectNotFound: (Microsoft.Power...ets.FindPackage:FindPackage) [Find-Package], Exception
          + FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.FindPackage

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

brywang-msft commented 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:

Repro

Steps

  1. Install WMF for PS4 on Server 2012 R2
  2. Save-Module PowerShellGet
  3. Install latest PSGet and PackageManagement (this happens on 1.1.4 and 1.1.3 at least)
  4. save-module packagemanagement -requiredversion 1.1.3.0 -path $somePath (also tried xjea)

Expected results

Package is saved or a real error is shown

Actual results

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
bmanikm commented 7 years ago

@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 commented 7 years ago
  1. Indeed, seems like it's coming from PSGet. Will open this issue there.
  2. I don't see any issue and it should be a small change - willing to take it into the next version as we're going to have to do a full test matrix anyways. @jianyunt can you see any issue with this?
jianyunt commented 7 years ago

@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.

jianyunt commented 7 years ago

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()

brywang-msft commented 7 years ago

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.

jianyunt commented 7 years ago

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.