Exporting/Using Microsoft.WinGet.Client as a C# NuGet Package

[JulianPritchard]

Ask:

When interacting with the winget-cli programmatically there are two recommended approaches: ComInterop, and PowerShell
Generally, when working in a .Net context the answer would be ComInterop
However, I'm making something that could be used as PowerShell binary module

In this flow I'd like to wrap/extend some functionality of the Microsoft.WinGet.Client, by using the PowerShell.SDK to add new commands which use the existing module's API

In order to achieve the above: a NuGet package which has transitive design time build references would be needed
PowerShell Package Content has the ref/net8.0/... with 4 pairs of dll/xml files which are an example of such references

Unlike the PowerShell SDK, there wouldn't be a need to include runtime assets in the package as those would be loaded be PowerShell itself when it loads the WinGet.Client module
In essence I think what I'm asking for is somewhat the reverse of ReferenceEmbeddedCsWinRTProject.targets @JohnMcPMS added to have the .winmd not referenced, but included in the output

Though there might be a simpler way of achieving this?

Original Ask

Would it be possible to have an export of the [PowerShell Winget Client Module](https://www.powershellgallery.com/packages/Microsoft.WinGet.Client/1.10.340) that could be consumed as a NuGet package for a .Net project?

Background:

I'm currently building a tool which is similar to the DSCv3, in that it can be used to bootstrap a dev's machine

Unfortunately, DSCv3 doesn't fully meet our needs, as we have legacy dependencies and esoteric environment configurations
Due to the above I've built a flow around the PowerShell SDK. With the WinGet bootstrap being similar to that for WSB

I was hoping to just use the PowerShell modules, and avoid the COM Interop route

This approach worked quite well, and I noticed that when debugging the WinGet.Client module was being loaded from %USERPROFILE%\Documents\PowerShell\Modules\Microsoft.WinGet.Client\1.10.340\net8.0-windows10.0.22000.0\Microsoft.WinGet.Client.Cmdlets.dll

Issue:

The issue is that while the library loads fine at runtime it currently isn't available as a development dependency that can be used for typing/static analysis during development as follow

using System.Management.Automation;
using System.Management.Automation.Runspaces;

using Microsoft.PowerShell;
using Microsoft.WinGet.Client.Engine.PSObjects; // <-- No Package to reference this assembly

// Without the above assembly,
// PSInstalledCatalogPackage type (which exists at runtime) cannot be used
public async Task<PSDataCollection<PSInstalledCatalogPackage>> GetInstalledPackages()
{
    var initialSession = InitialSessionState.CreateDefault();
    initialSession.ExecutionPolicy = ExecutionPolicy.Bypass;
    var powerShell = PowerShell.Create(initialSession);

    PSDataCollection<PSObject> input = null;
    var output = new PSDataCollection<PSInstalledCatalogPackage>();

    powerShell.Commands = new PSCommand().AddCommand("Get-WingetPackage");
    await powerShell
        .InvokeAsync(input, output)
        .ConfigureAwait(false);
    return output;
}

Details

The above code sample will run in a .Net8 Console Application, with top level statements enabled, and the repacking of the PowerShell module described below

I managed to achieve the above by getting the .nupkg from PowerShellGallery, extracting it as a zip, rather clumsily reorganized the files and folders, added a bit to the .nuspec file, and used nuget pack .\microsoft.winget.client.repack.nuspec to repack the module as a regular .Net package that can be used in a project

While the above works, I really don't believe how I've managed to get it to work is good practice, or something I'd recommend doing. The PowerShell Module supports both (".Net48", ".Net8") TFMs, and ("arm64", "x64", "x86") CPUs which I've had to narrow to .Net8-x64 due to the application now trying to load the dependencies from the package¹

Outcomes:

• A Microsoft.WinGet.Client nupkg for regular .Net libraries
  • I understand the above might be a pain and not something that the team wants to maintain
• If the above isn't feasible, then some advice to achieve the outcomes would be greatly appreciated

Edit:
Updated ask with some clarification in response to florelis's answer, original ask now in details block

Footnotes

1. There's likely a way to have the client assembly as a development dependency and then use AssemblyLoadContext.GetLoadContext to ensure that PowerShell module is loaded appropriately at runtime. ↩

[florelis]

We have a sample project for how to consume the COM API package. It should be pretty straightforward without needing to deal with interop. Unless you want to use Configuration or run it inside your own process, which would need some magic in your .csproj and actually dealing with COM.

[JulianPritchard]

Hi @florelis,

Thanks for the help, it's really appreciated!
I have tried the OutOfProc, and it could work. I've added some notes of issues I ran into to hopefully update the samples to help people in the future

ComInterop

I was unaware of the OutOfProc flow which is much more convenient than InProc which I'd setup following UniGet/DevHome

There was an issue I encountered following the OutOfProc Sample:

Microsoft.WindowsPackageManager.ComInterop.common.targets(10,5):
 Error  : Microsoft.Management.Deployment.dll could not be copied because the AnyCPU platform is being used.
Please specify a platform to copy this file, using either RuntimeIdentifier, an architecture specific Platform, or explicitly with MicrosoftManagementDeployment-Platform.

It seems like any means of targeting multiple Platforms have the issue:

• <Platforms>x64;ARM64;x86</Platforms>
• <PlatformTargets>x64;ARM64;x86</PlatformTargets>
• <RuntimeIdentifiers>win-x64;win-arm64;win-x86</RuntimeIdentifiers>

And, they need to be used in combination with <MicrosoftManagementDeployment-Platform>x64</MicrosoftManagementDeployment-Platform> property

Only <RuntimeIdentifier>win-x64</RuntimeIdentifier> by itself worked

Would it be possible to target multiple platforms with this flow?
I haven't found a way, and it'd be useful to update the sample if there is

---

Between the original post and this, I think I've narrowed what the ask from my side is:

Clarified Ask

When interacting with the winget-cli programmatically there are two recommended approaches: ComInterop, and PowerShell
Generally, when working in a .Net context the answer would be ComInterop
However, I'm making something that could be used as PowerShell binary module

In this flow I'd like to wrap/extend some functionality of the Microsoft.WinGet.Client, by using the PowerShell.SDK to add new commands which use the existing module's API

In order to achieve the above: a NuGet package which has transitive design time build references would be needed
PowerShell Package Content has the ref/net8.0/... with 4 pairs of dll/xml files which are an example of such references

Unlike the PowerShell SDK, there wouldn't be a need to include runtime assets in the package as those would be loaded be PowerShell itself when it loads the WinGet.Client module
In essence I think what I'm asking for is somewhat the reverse of ReferenceEmbeddedCsWinRTProject.targets @JohnMcPMS added to have the .winmd not referenced, but included in the output

Though there might be a simpler way of achieving this?

[florelis]

I was unaware of the OutOfProc flow which is much more convenient than InProc which I'd setup following UniGet/DevHome

I believe those two use the InProc version to either be able to work regardless of the version of winget that is on the system, or to be able to run as admin. With the OutOfProc version, you are launching a COM server from the installed winget and any COM objects you use live in that process. The server by default runs as a regular user, and uses the version of winget that you have installed. With InProc, you are creating the objects in your own process, so you are using a DLL included in the package and run with the same privileges, but it has added complexity due to needing to create the COM objects directly.

Error : Microsoft.Management.Deployment.dll could not be copied because the AnyCPU platform is being used.
Please specify a platform to copy this file, using either RuntimeIdentifier, an architecture specific Platform, or explicitly with MicrosoftManagementDeployment-Platform.

For context: The DLLs in the package are native code, so it targets specific platforms even if your project is AnyCPU. You need to specify a platform to select between the available winget DLLs.

Although there may be a way to include all three DLLs with your project and select the one you want at runtime...

Would it be possible to target multiple platforms with this flow?

The OutOfProc sample targets multiple platforms. Does that not work for you?

Clarified Ask

I'm not saying this is a good idea but...
At the end of the day, you can get the PS module as a nupkg from the PS Gallery. So in theory you could reference that package, and the binaries in it.