Get-PackageSource does not list registered sources (1.4)

[arcotek-ltd]

Firstly, this is going to be a quick one. I will add more detail asap / as required.

See similar issue https://github.com/OneGet/oneget/issues/386 from October 2018.

Windows 10 Enterprise, 1809, clean build.

1. Install-Module PackageManagement Results in version 1.4 installed.

2. Install-Module PowerShellGet Results in version 2.1.4 installed.

3. Delete version 1.0.0.1 of the above two modules

4. Run:

   Register-PackageSource `
   -Name "myGallery" `
   -Location "https://contoso.pkgs.visualstudio.com/_packaging/myGallery/nuget/v2" `
   -Credential $RepoCreds `
   -Trusted `
   -Force `
   -Provider "NuGet"`
   -Verbose

5. Run Get-PackageSource. Only PSGallery is listed.

If I do the same using DSC PackageManagementSource resource, the source registers and on subsequent runs, the source is "Present", however running the exact same cmd used by DSC, does not return the source.

I downgraded PackageManagement to 1.3.2 (not PowerShellGet), deleted 1.4, reloaded PowerShell and ran the same commands (1 - 5). This time my source was listed.

I installed 1.4 again, removing 1.3.2 and reloading PowerShell, repeated commands 1 - 5 and this time Get-PackageSource shows my source.

Something very strange is going on here. If you want to fix this one, I'm happy to provide logs, but I'd be grateful if I can email them to you, to save me spending hours redacting them.

I'm going to revert the VM snapshot and instead of upgrading to 1.4, I'll go with 1.3.2 and see if the problem manifests itself. I'll update here with results...

Thanks

[arcotek-ltd]

I've made a little progress.

1. Install-Package -Name PowerShellGet
2. Close PowerShell sessions.
3. Delete 1.0.0.1 PowerShellGet & PackageManagement old modules. (Can't use Uninstall-Package as they weren't installed with PSGet :-( ).
4. Register-PackageSource -Name $PackageFeedName -Location $PackageFeedUri -ProviderName "NuGet" -Credential $RepoCreds -Trusted -Confirm:$false -Force -Verbose
5. Get-PackageSource now lists my repo.

I've discovered PackageManagement is a dependency of PowerShellGet. I guess my initial findings may have had something to do with a lock on a bunch of DLLs in PackageManagement. By closing PowerShell, this released the locks.

BUT

DSC still doesn't work, however, I have discovered why, but I don't know what the solution is.

When I run Register-PackageSource, it is in the context of a user, and thus updates C:\Users\{user}\AppData\Roaming\NuGet\NuGet.Config, however, when run with DSC, it is run in the context of SYSTEM and therefore writes to C:\Windows\System32\config\systemprofile\AppData\Roaming\NuGet\NuGet.Config

This explains why DSC sees it as Present on subsequent runs, but it doesn't explain why Get-PackageSource cannot see it, unless this is by design, but why would it be? Are you saying that Get-PackageSource only has scope of a user? I expect DSC's PsDscRunAsCredential would partially resolve the issue, but I want the source registered for all users of the machine. Besides, my design dictates that DSC should do everything before a user logs on. Yes, I could start playing with logon scripts / .Default profile and the like, but the more elegant solution would be to get Get-PackageSource and related cmdlets to work at the computer scope. (Install-Module has a -Scope parameter).

Open to suggestions...

[arcotek-ltd]

It looks as though all Register-PackageSource does is write to the NuGet.Config file, so I will see what happens if I create / update this file in .Default profile.