dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
14.86k stars 4.62k forks source link

System.Management has a dependency on .NET Framework #66386

Open Symbai opened 2 years ago

Symbai commented 2 years ago

Description

I've ported an application to .NET 6 and added nuget package of System.Management. It shows .NET 6 as supported, it depends on System.Codedom which also shows .NET 6 support. Apart of that no other dependencies. I've published my app as self-contained and ran it on a Windows 8.1 machine. It crashed and the event viewer got an entry saying:

System.PlatformNotSupportedException: The native library 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\wminet_utils.dll' does not have all required functions. Please, update the .NET Framework.

Reproduction Steps

Create a new .NET 6 project Add System.Management nuget package Publish self contained Run on a machine with an outdated .NET framework

Expected behavior

I've expected that because its .NET6 and because it's self contained that it "just works" and that it does not depend on any .NET Framework installation. If it requires any additional native files, it should copy these to the publish folder of the .NET 6 self contained app.

Actual behavior

Application crashes, because it depends on (a specific) .NET Framework (version)

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

dotnet-issue-labeler[bot] commented 2 years ago

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

ghost commented 2 years ago

Tagging subscribers to this area: @dotnet/area-system-management See info in area-owners.md if you want to be subscribed.

Issue Details
### Description I've ported an application to .NET 6 and added nuget package of `System.Management`. It shows .NET 6 as supported, it depends on `System.Codedom` which also shows .NET 6 support. Apart of that no other dependencies. I've published my app as self-contained and ran it on a Windows 8.1 machine. It crashed and the event viewer got an entry saying: `System.PlatformNotSupportedException: The native library 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\wminet_utils.dll' does not have all required functions. Please, update the .NET Framework.` ### Reproduction Steps Create a new .NET 6 project Add System.Management nuget package Publish self contained Run on a machine with an outdated .NET framework ### Expected behavior I've expected that because its .NET6 and because it's self contained that it "just works" and that it does not depend on any .NET Framework installation. If it requires any additional native files, it should copy these to the publish folder of the .NET 6 self contained app. ### Actual behavior Application crashes, because it depends on (a specific) .NET Framework (version) ### Regression? _No response_ ### Known Workarounds _No response_ ### Configuration _No response_ ### Other information _No response_
Author: Symbai
Assignees: -
Labels: `area-System.Management`, `untriaged`
Milestone: -
stephentoub commented 2 years ago

Duplicate of https://github.com/dotnet/runtime/issues/45143 cc: @danmoseley, @ericstj

Symbai commented 2 years ago

FYI: The suggested "solution" in #45143 by switching to Microsoft.Management.Infrastructure (apart from the fact that it works different and all snippets on the internet are for System.Management which makes switching difficult) is that it also doesn't work. Now the app is crashing with System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Management.Infrastructure,...

This is because this file is also not copied to publish folder when published through VS. IF I have to copy the file myself then I can also copy wminet_utils.dll myself instead. That doesn't seem to be the right solution.

ericstj commented 2 years ago

Now the app is crashing with System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Management.Infrastructure,...

We don't support MMI here, for issues with it you may file them here https://github.com/PowerShell/MMI. It should work and many have been successful using it. Here's a sample: https://github.com/ericstj/sample-code/blob/mmi-samples/mmi-samples/Program.cs. You can also find usage in https://github.com/powershell/powershell.

The problem is not that wminet_utils.dll is missing, it's that it's old. .NETFramework is part of the OS and we require a particular minimum version of the operating system + updates for this component to work. https://github.com/dotnet/runtime/issues/29663 discusses this. I believe most versions of .NETFramework that are still in support have the required changes.

Symbai commented 2 years ago

Isn't it possible to just copy the required files (the right version of wminet_utils.dll for example) to publish folder and use that one? What else is the meaning of self contained when it doesn't contain all required files? And when it's not possible, shouldn't System.Management at least get a warning somewhere that it's not fully .NET (Core) compatible because it requires .NET Framework?

danmoseley commented 2 years ago

What else is the meaning of self contained when it doesn't contain all required files?

From the publishing point of view, it's not that different to user code calling into a native library - it doesn't know about it. This is even more of a corner case, as you only need a local copy if you are deploying to machine with .NET Framework older than 4.6.2. (And BTW, I am not sure we have actually tested with a local copy.)

shouldn't System.Management at least get a warning somewhere that it's not fully .NET (Core) compatible because it requires .NET Framework?

If there's a good place in the docs we can add the note that System.Management requires .NET Framework 4.6.2 or later.

Note that .NET Framework, and thus wminet_utils.dll, is part of the OS on all "regular" Windows SKU's. Instead of thinking of this as ".NET Core still depends on .NET Framework" it may be better to think of this as "this legacy .NET feature requires a particular version of a Windows component"

Symbai commented 2 years ago

From the publishing point of view, it's not that different to user code calling into a native library - it doesn't know about it

On publishing a WPF application it does copy native files WPF requires to the output folder. Why can it do that on WPF but not when System.Management (or MMI) is referenced? Or let me rephrase that: If it's able to do that on WPF, can we do the same on System.Management (or MMI)? Both (all three) are not third party but products of Microsoft. And developers referencing System.Management may not know that it relies on .NET Framework (or a Windows component), just like me. They might reference and deploy it as self contained assuming it "just works" and wonder why their customers report it just crashes.

stepagrus commented 1 year ago

I solved this question for myself by switching to the WMILight library instead of System.Management