Plans to migrate to Microsoft.Management.Infrastructure namespace?

[mmashwani]

I love this project. It really makes WMI much easier to use in C#. However, I was wondering if there are any plans to migrate the project to start using the Microsoft.Management.Infrastructure namespace instead of System.Management. Here is what Microsoft has to say about the choice between the two:

System.Management was the original namespace that covered managed code for WMI. However, the underlying technology for System.Management is generally slower than, and does not scale as well as, Microsoft.Management.Infrastructure. As such, it is not recommended that you use System.Management for new projects.

https://docs.microsoft.com/en-us/previous-versions/hh872326(v=vs.85)

[mmashwani]

Another idea could to be let user's choose which namespace they want to use. Have a default and then allow users to over ride the default if there is some reason to continue using System.Management.

[nicoriff]

@mmashwani thanks for using ORMi. There are no plans no migrate to Microsoft.Management.Infrastructure on the current .NET Framework version. But I will start to work to migrate to .NET Core which will use https://www.nuget.org/packages/System.Management/ Anyway, IMHO there aren't big performance improvements in Microsoft.Management.Infrastructure. On performance, hard to know difference.

[chucker]

IMHO there aren't big performance improvements in Microsoft.Management.Infrastructure

Have you actually tested this? I imagine Microsoft has reasons to make such a claim.

[nicoriff]

@chucker I´ve done some applications using Microsoft.Management.Infraestructure. I really didn't see any big performance enhancements in any of those project. That does not mean that Microsoft.Management.Infraestructure is slower or bad implemented or anything like that. It is just my opinion, and the truth is that in the short term I'm not planning to use Microsoft.Management.Infraestructure as it implies big changes and I'm currently not having that much time to make it. In the future it will be the way to go as System.Management is considered legacy code.

Luckily Microsoft have ported System.Management to .NET Core so it will be easy to migrate to .NET Core in the short term.

[mmashwani]

Besides performance, there are some other advantages to using the Microsoft.Management.Infrastructure namespace. The main one I am interested in is it's ability to use WinRM for remoting.

I haven't looked at it in great detail yet, but the method for creating a connection using either namespace doesn't seem all that different or complicated: https://docs.microsoft.com/en-us/windows/desktop/wmisdk/connecting-to-wmi-remotely-with-c-

Here are a couple of articles talking about advantages to the new namespace: https://blogs.msdn.microsoft.com/wmi/2013/05/16/introducing-new-management-infrastructure-mi-api/ https://docs.microsoft.com/en-us/previous-versions/windows/desktop/wmi_v2/why-use-mi-

From my understanding of it, as a consumer of WMI data, the new namespace mainly offers advantages in how it connects to remote machines to query data. Most of the advantages seem to be geared towards developers creating WMI providers.

Still, WMI remoting is an important use case for me in most environments. In a few months time, when my work load clears a little bit, I may make an attempt at enabling support for the new namespace and submitting a pull request.

[nicoriff]

@mmashwani I will reopen and leave this issue open. When I have a little more time I will analize the impact of making such change. I also think that the migration should be complete. There will be no point of making the dev to select between one or other technology at least in first place. The aim of ORMi is to make as simplified as possible writing the less code possible.

[Vercidium]

Hey, just following up on this. Has ORMi been ported to .NET Core and will it work in an application built for net5.0-windows?

[Symbai]

Just a small note and warning: System.Management requires a specific minimum of .NET framework version unlike MMI. For self contained deployment of a .NET (Core) application this is a huge problem. MMI doesn't have this problem.