Skip to content
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

Closed
czb182 opened this issue Jan 26, 2018 · 8 comments
Closed

Microsoft.Management.Infrastructure vs System.Management #24803

czb182 opened this issue Jan 26, 2018 · 8 comments
Labels
area-System.Management question Answer questions and provide assistance, not an issue with source code or documentation.
Milestone

Comments

@czb182
Copy link

czb182 commented Jan 26, 2018

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.

@iSazonov
Copy link
Contributor

Good question. I wonder too that WMI instead of MMI was ported to .Net Core.
PowerShell Core depends on MMI and currently uses limited version https://www.nuget.org/packages/Microsoft.Management.Infrastructure/ . Tracking Issue PowerShell/PowerShell#4562.

/cc @SteveL-MSFT

@danmoseley
Copy link
Member

We ported System.Management purely to make it easier to port legacy code to.NET Core. We don't recommend new code use it.
@ViktorHofer could you please check whether MMI has complete functionality on.NET Core?

@ViktorHofer
Copy link
Member

will do.

@ViktorHofer
Copy link
Member

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.

@iSazonov
Copy link
Contributor

We don't recommend new code use it.

@danmosemsft It would be good to know what MSFT recommends instead. (Is there a documentation, a blog article or an Issue?)

@SteveL-MSFT
Copy link
Contributor

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.

@czb182
Copy link
Author

czb182 commented Feb 21, 2018

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
https://www.nuget.org/packages/Microsoft.Management.Infrastructure/

@SteveL-MSFT
Copy link
Contributor

@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.

@Anipik Anipik closed this as completed Mar 15, 2018
Dotnet-GitSync-Bot referenced this issue in Dotnet-GitSync-Bot/corefx Sep 10, 2019
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]>
stephentoub referenced this issue in dotnet/corefx Sep 10, 2019
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]>
@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 2.1.0 milestone Jan 31, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 18, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Management question Answer questions and provide assistance, not an issue with source code or documentation.
Projects
None yet
Development

No branches or pull requests

7 participants