-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Microsoft.Management.Infrastructure vs System.Management #24803
Comments
Good question. I wonder too that WMI instead of MMI was ported to .Net Core. /cc @SteveL-MSFT |
We ported System.Management purely to make it easier to port legacy code to.NET Core. We don't recommend new code use it. |
will do. |
The API is compatible with .NET Standard 2.0, only SecurityContext was problematic. Had to add a nuget package and cross-compile as SecurityContext throws on Core because it's stubbed out. |
@danmosemsft It would be good to know what MSFT recommends instead. (Is there a documentation, a blog article or an Issue?) |
On Windows, we recommend using Microsoft.Management.Infrastructure namespace (aka WMIv2). System.Managmeent (aka WMIv1) is deprecated. On non-Windows, we currently don't have plans to port either namespace. |
https://blogs.msdn.microsoft.com/powershell/2018/01/24/powershell-core-6-1-roadmap/ powershell core 6.1 will bring WMI, leveraging .net windows compatibility pack. So this means WMI with powershell core WMI will be built over System.Management rather than MMI? If MMI could be made NetStandard compatible, then maybe it would be useful for powershell team and included in compatibility pack? Maybe then we could get netstandard compatible version of library on nuget to replace |
@czb182 The WindowsPowerShellCompatibilityPack module will be optional. On Windows, the CIM cmdlets are part of the PSCore6 distribution. Not sure if we'll get to porting the WMI cmdlets in 6.1 timeframe as it's turned out to be a much bigger work item than originally anticipated. As for MMI being NetStd compatible, I don't think this is possible as MMI is written in managed C++ which is no longer supported by dotnet. |
Also removes dependency on System.Range and RuntimeHelpers.GetSubArray in a simple console app such that they can be trimmed away. Signed-off-by: dotnet-bot <[email protected]>
Also removes dependency on System.Range and RuntimeHelpers.GetSubArray in a simple console app such that they can be trimmed away. Signed-off-by: dotnet-bot <[email protected]>
This is more of a question than an issue, but wasn't sure where else to ask.
I just got starting working with WMI via C# using FullCLR. I am consuming the Microsoft.Management.Infrastructure assembly since it was describing as being the modern version of System.Management here https://msdn.microsoft.com/en-us/library/mt703458(v=vs.85).aspx
I was trying to look into a CoreCLR version of Microsoft.Management.Infrastructure and heard about the Windows Compatibility Pack, so found myself here. I was surprised to see System.Management instead of Microsoft.Management.Infrastructure in repo, since I thought the former was basically deprecated from link I posted above.
My question is basically should I revert to using System.Management for compatibility with CoreCLR in future, or is there a CoreCLR version of Microsoft.Management.Infrastructure coming? I am new to WMI and would appreciate any clarification.
The text was updated successfully, but these errors were encountered: