Feature Request: MMI NuGet Portable Windows RIDs

[theimowski]

Summary of the new feature/enhancement

I've posted the original question here but I'm not sure if that repo gets enough attention from PowerShell team.

Proposed technical implementation details (optional)

My use case is I have a .NET Core console application which is distributed to all major OS. For windows we want to query WMI. As far as I managed to find out, Microsoft suggest to migrate from System.Management dll to Microsoft.Management.Infrastructure - details in https://github.com/dotnet/corefx/issues/31447

I'm happy to move drop System.Management in favour of MMI but my issue is that MMI currently ships with non-portable RIDs:

└── runtimes
    ├── unix
    ├── win-arm
    ├── win-arm64
    ├── win10-x64
    ├── win10-x86
    ├── win7-x64
    ├── win7-x86
    ├── win8-x64
    ├── win8-x86
    ├── win81-x64
    └── win81-x86

while we use the portable RIDs: win-x64 and win-x86 for the Self contained app.

So the request would be to publish MMI as a package with portable RIDs for windows

[iSazonov]

Right reference https://github.com/dotnet/corefx/issues/26601

[TravisEz13]

cc @adityapatwardhan

[TFoxik]

Any update on this? This would help us a lot. Our use case is very similar to @theimowski , we do have .NET core 3.1 application which is distributed to all major OS and we would like to use Powershell.SDK but because of the missing portable RIDs in MMI it is not currently possible.

[TravisEz13]

I got permission to and transferred the issue to the correct repo. @adityapatwardhan would still be the right person.

[theimowski]

I've just noticed that MMI 2.0.0 has a different nupkg structure:

tree -L 2 ~/.nuget/packages/microsoft.management.infrastructure/1.0.0/
/Users/theimowski/.nuget/packages/microsoft.management.infrastructure/1.0.0/
├── [Content_Types].xml
├── _rels
├── microsoft.management.infrastructure.1.0.0.nupkg
├── microsoft.management.infrastructure.1.0.0.nupkg.sha512
├── microsoft.management.infrastructure.nuspec
├── package
│   └── services
├── paket-installmodel.cache
├── ref
│   ├── net451
│   └── netstandard1.6
└── runtimes
    ├── unix
    ├── win-arm
    ├── win-arm64
    ├── win10-x64
    ├── win10-x86
    ├── win7-x64
    ├── win7-x86
    ├── win8-x64
    ├── win8-x86
    ├── win81-x64
    └── win81-x86

vs

tree -L 2 ~/.nuget/packages/microsoft.management.infrastructure/2.0.0/
/Users/theimowski/.nuget/packages/microsoft.management.infrastructure/2.0.0/
├── [Content_Types].xml
├── _rels
├── lib
│   └── netstandard1.6
├── microsoft.management.infrastructure.2.0.0.nupkg
├── microsoft.management.infrastructure.2.0.0.nupkg.sha512
├── microsoft.management.infrastructure.nuspec
├── package
│   └── services
├── paket-installmodel.cache
└── ref
    ├── net451
    └── netstandard1.6

Does it mean that MMI 2.0 supports now portable RIDs? I.e. can I publish the app to win-x86 and win-x64 and expect it to work on all .net core supported windows versions?

[TravisEz13]

Win-* would not support linux... I'll have to let @adityapatwardhan speak for the rest of windows. We compile with win7-x64 for all windows environments.

[theimowski]

Win-* would not support linux

Yup that's clear

What's the rationale for using win7-x64 instead of the more generic win-x64? I.e. is there any difference between publishing to those two RIDs and if so what is the difference?

We have customers still running Windows 6.0 (Server 2008), and while I'm aware that net core doesn't support that OS, I know that net core can run on that OS - would using win7-x64 RID result in a binary that can't be run on Windows 6.0?

[TravisEz13]

@theimowski It comes from a bug in .NET really.. It chooses a non-generic windows API set when we publish fro win-x64.

[theimowski]

Oh that's interesting - do you have some link / reference that describes that bug? Is that documented anywhere?

[TravisEz13]

TBH, the issue may be fixed. The issue was way back in our initial release and we just have not found any reason to change it. We should try changing it as Win7 is no longer supported by .NET or PowerShell

[TravisEz13]

@ShadowXVII I'm actively working on store compatibility. PowerShell/PowerShell#12582
I'm blocked where Windows is not accepting the signature.
Please discuss store compatibility in that PR.

[adityapatwardhan]

Sorry for coming late to this discussion. The reason we have so many RIDs is that the binaries are different for each OS. Though the code in mi.dll is same, the dependencies are different per OS. That was the reason for creating so many RID folder and not just using win-x64 and win-x86

[theimowski]

@adityapatwardhan are the differences between the binaries documented somewhere?
Asking, since one could analyse those differences to tell whether the API they are using from Microsoft.Management.Infrastructure actually requires multi targeting.

[adityapatwardhan]

Microsoft.Management.Infrastructure.dll depends on mi.dll which as the native implementation. mi.dll depends on various Windows APIs. There is a difference between those APIs / native binaries which makes us use runtime folders for each supported OS.

[jaelys]

We accept Microsoft’s promotion and use .NET 6
Migrating from WMI to MMI, but we always encounter difficult problems to solve, but we have to wait all the time. Can this problem still receive attention? Should we continue to look forward to it?

Or shouldn't be a standalone release, but should use runtime to solve this kind of problem?

[pocki]

After updating my App to .NET8 I get now warnings:
warning NETSDK1206: Found version-specific or distribution-specific runtime identifier(s): win10-x64, win10-x86, win7-x64, win7-x86, win81-x64, win81-x86, win8-x64, win8-x86. Affected libraries: Microsoft.Management.Infrastructure.Runtime.Win. In .NET 8.0 and higher, assets for version-specific and distribution-specific runtime identifiers will not be found by default. See https://aka.ms/dotnet/rid-usage for details.