search

PowerShell / MMI

Other
25 stars 17 forks source link

Feature Request: MMI NuGet Portable Windows RIDs #45

Open theimowski opened 5 years ago

theimowski commented 5 years ago

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

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

TravisEz13 commented 5 years ago

cc @adityapatwardhan

TFoxik commented 4 years ago

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

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

theimowski commented 4 years ago

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

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

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

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

theimowski commented 4 years ago

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

TravisEz13 commented 4 years ago

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

XVII commented 4 years ago

Hmm, is this related to Could not load file or assembly 'Microsoft.Management.Infrastructure, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified. I get only when running in deployed package via store?

Tried Microsoft.Management.Infrastructure.Runtime.Win but my app continues to complain about that missing binary.

Was using <RuntimeIdentifiers>win-x64;win-x86</RuntimeIdentifiers> -- changing them to win10 didn't help.

If it's unrelated, I'll open another issue.

Stack Trace

File name: 'Microsoft.Management.Infrastructure, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
   at System.Management.Automation.CimClassDeserializationCache`1..ctor()
   at System.Management.Automation.DeserializationContext..ctor(DeserializationOptions options, PSRemotingCryptoHelper cryptoHelper)
   at System.Management.Automation.Remoting.Fragmentor..ctor(Int32 fragmentSize, PSRemotingCryptoHelper cryptoHelper)
   at System.Management.Automation.Remoting.BaseTransportManager..ctor(PSRemotingCryptoHelper cryptoHelper)
   at System.Management.Automation.Remoting.Client.BaseClientTransportManager..ctor(Guid runspaceId, PSRemotingCryptoHelper cryptoHelper)
   at System.Management.Automation.Remoting.Client.BaseClientSessionTransportManager..ctor(Guid runspaceId, PSRemotingCryptoHelper cryptoHelper)
   at System.Management.Automation.Remoting.Client.WSManClientSessionTransportManager..ctor(Guid runspacePoolInstanceId, WSManConnectionInfo connectionInfo, PSRemotingCryptoHelper cryptoHelper, String sessionName)
   at System.Management.Automation.Runspaces.WSManConnectionInfo.CreateClientSessionTransportManager(Guid instanceId, String sessionName, PSRemotingCryptoHelper cryptoHelper)
   at System.Management.Automation.Remoting.ClientRemoteSessionDSHandlerImpl..ctor(ClientRemoteSession session, PSRemotingCryptoHelper cryptoHelper, RunspaceConnectionInfo connectionInfo, URIDirectionReported uriRedirectionHandler)
   at System.Management.Automation.Remoting.ClientRemoteSessionImpl..ctor(RemoteRunspacePoolInternal rsPool, URIDirectionReported uriRedirectionHandler)
   at System.Management.Automation.Internal.ClientRunspacePoolDataStructureHandler.CreateClientRemoteSession(RemoteRunspacePoolInternal rsPoolInternal)
   at System.Management.Automation.Internal.ClientRunspacePoolDataStructureHandler..ctor(RemoteRunspacePoolInternal clientRunspacePool, TypeTable typeTable)
   at System.Management.Automation.Runspaces.Internal.RemoteRunspacePoolInternal.CreateDSHandler(TypeTable typeTable)
   at System.Management.Automation.Runspaces.Internal.RemoteRunspacePoolInternal..ctor(Int32 minRunspaces, Int32 maxRunspaces, TypeTable typeTable, PSHost host, PSPrimitiveDictionary applicationArguments, RunspaceConnectionInfo connectionInfo, String name)
   at System.Management.Automation.Runspaces.RunspacePool..ctor(Int32 minRunspaces, Int32 maxRunspaces, TypeTable typeTable, PSHost host, PSPrimitiveDictionary applicationArguments, RunspaceConnectionInfo connectionInfo, String name)
   at System.Management.Automation.RemoteRunspace..ctor(TypeTable typeTable, RunspaceConnectionInfo connectionInfo, PSHost host, PSPrimitiveDictionary applicationArguments, String name, Int32 id)
   at System.Management.Automation.Runspaces.RunspaceFactory.CreateRunspace(RunspaceConnectionInfo connectionInfo, PSHost host, TypeTable typeTable, PSPrimitiveDictionary applicationArguments, String name)
   at System.Management.Automation.Runspaces.RunspaceFactory.CreateRunspace(RunspaceConnectionInfo connectionInfo, PSHost host, TypeTable typeTable)
   at System.Management.Automation.Runspaces.RunspaceFactory.CreateRunspace(PSHost host, RunspaceConnectionInfo connectionInfo)
   at System.Management.Automation.Runspaces.RunspaceFactory.CreateRunspace(RunspaceConnectionInfo connectionInfo)
TravisEz13 commented 4 years ago

@ShadowXVII What do you mean:

running in deployed package via store?

Anyway, this binary just comes with windows. I'm guessing you mean the Windows Store. That is experimental and there is an issue where it cannot access all resources. This issue is probably the cause.

XVII commented 4 years ago

@ShadowXVII What do you mean:

running in deployed package via store?

When my msix package is deployed via the Windows Store I get the issue mentioned above. When it runs locally (undeployed) it works fine. It used to work, so I suspect a package update or similar has changed things :(

Maybe it's not related then.

Anyway, this binary just comes with windows. I'm guessing you mean the Windows Store. That is experimental and there is an issue where it cannot access all resources. This issue is probably the cause.

Do you mean using MMI in a store sandboxed app? Ok. I might have to go back to an older version that worked -- might've been dotnet 3.1.

XVII commented 4 years ago

Also @TravisEz13, is the store compatibility something I should raise as a new issue in this repo? Same error but perhaps different causes.

TravisEz13 commented 4 years ago

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

adityapatwardhan commented 4 years ago

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

@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 commented 4 years ago

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

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 commented 10 months ago

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.