Using System.Management for Self Contained Apps required specific full .NET version

[theimowski]

I'd like to revisit https://github.com/dotnet/corefx/issues/31447

Following code for self contained .NET Core 2.1 console app on Windows 8.1 Pro with .NET 4.5.1:

      use mo = new ManagementObjectSearcher("root\\CIMV2", "select * from win32_computersystem")
      use col = mo.Get()
      col
      |> Seq.cast<ManagementObject>
      |> Seq.head
      |> fun t -> t.GetPropertyValue("totalphysicalmemory")

Experienced following exception:

The type initializer for 'System.Management.WmiNetUtilsHelper' threw an exception. ---> System.ArgumentNullException: Value cannot be null.
Parameter name: ptr

When I update System.Management to latest preview version (4.6.0-preview5.19224.8), the exception changes to:

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.

which is obviously more informative, however .NET Core is supposed to support Windows 8.1 OOTB.
Is this a known issue, or a "won't fix" due to one actually needs recent full .NET Framework to use System.Management?

[danmoseley]

Based on the above yes it seems you must update your.NET Framework version to at least match the snap of the code we made. But as mentioned in the other issue if it is important to you you could investigate whether it is feasible to make the code more tolerant. It is unlikely we will have time to do this.

[theimowski]

update your.NET Framework version to at least match the snap of the code we made

what do you mean by "match snap of code"?

Anyway updating .NET Framework isn't really a viable option - we need the application to be "Self contained" as it's distributed among many client machines.
Apparently Self Contained does not really work for .NET Core and System.Management to query WMI.

In this case, do you recommend to switch from System.Management to Microsoft.Management.Infrastructure instead?

[danmoseley]

@theimowski i didn't provide context. The WMI functionality in.NET Framework is split across native and managed code. We did not want to port the native code into.NET Core. We thought it is OK to require the native binary exist on the machine as is it part of.NET Framework so part of Windows. However we had to port the managed part so that it could run on Core. To do this we snapped a copy of it from probably 4.6.2 or thereabouts into the Corefx repo. If the WMI implementation between 4.5 and 4.6.2 or whatever added a call to a new export from the native code, then the managed code would fail if it was not found ie if it was run on a machine that did not have at least 4.6.2. This is presumably the issue you see.
I do not know which export this is (would show up easily in a debugger) but it is possible that it is not needed for the WMI functionality you need - it is just the code is written to bind to all expected exports when you use any WMI feature. If this is the case or could be adjusted to delay binding this function instead.

[danmoseley]

Apparently Self Contained does not really work for .NET Core and System.Management to query WMI.

In that it depends on the native part being up to date (4.6.2 most likely) your are correct

[danmoseley]

In this case, do you recommend to switch from System.Management to Microsoft.Management.Infrastructure instead?

I am not familiar with that technology. I know WMI is considered legacy and not advised for new projects. If MMI is newer (surely yes!) and supported on.NET Core then yes it is probably a better choice. If it is not then perhaps we can ask that team what they suggest (or to port it) Maybe @karelz knows.

[theimowski]

Thanks @danmosemsft for explanation, appreciate that.

I do not know which export this is (would show up easily in a debugger) but it is possible that it is not needed for the WMI functionality you need - it is just the code is written to bind to all expected exports when you use any WMI feature. If this is the case or could be adjusted to delay binding this function instead.

I could try investigate this however I don't fully understand how to do this - could you provide some more guidelines:

• what debugger to use,
• how to attach it,
• how to find the proper "export",
• how would a workaround look like if I found root cause?

Regarding MMI, I believe the alternative solution is using CimSession family of objects which suggests it doesn't use WMI (but not sure if that's really the case)

[danmoseley]

Re debugging you should be able to run the app under the Visual Studio debugger set to break on exceptions and then inspect the point at which it is being thrown - what the line of code is, the locals etc

[karelz]

@danmosemsft never heard of MMI before, so I can't help here :(

[theimowski]

I ended up using MMI - seems to do the job when .NET Framework is not in the newest version.
I don't think I'll come back to diagnosing why System.Management didn't work, installing Visual Studio on client machine just to trace the issue is not very convenient for me.
The issue can be closed now

[karelz]

You don't need to install VS to track down problems, but happy to close it ...

[natnan]

I have come across this on .NET Core 3.0 and think it is a valid issue for self-contained deployments. The same call that worked on .NET framework 4.5.2 now requires upgrading .NET framework on the machine when .NET Core is involved.

[danmoseley]

@natnan that's right, you do need an upgraded .NET Framework. It's a known limitation. As mentioned above, WMI is considered a legacy tech by my understanding, and we don't plan to port it wholesale to .NET Core. That is why we have this interop solution that requires an updated .NET Framework.

[natnan]

OK. thanks.

Created a question and answer for doing WMI queries on MMI: https://stackoverflow.com/questions/58641428/how-to-use-microsoft-management-infrastructure-mmi-instead-of-system-managemen/58641429#58641429

[natnan]

@danmosemsft, sorry to bring it up again but any chance this can be reconsidered? :)

From what I understand, the recommended way is to use MMI (Microsoft.Management.Infrastructure) instead of System.Management. However, MMI is barely documented (everything you google will give you WMI sample code), barely maintained and does not work on Windows 7. And not sure where this text comes from exactly, but VS 2019 NuGet even says that it's "Unofficial and unsupported".

There are certain information on Windows that seems to be only accessible via WMI. So this makes migrating from .NET Framework (4.5) to .NET Core quite hard. That said, there is still the workaround of running powershell commands using Process.Start, which we are going to use but that's not really ideal.