Port System.Management - WMI (Windows Management Instrumentation) or MI (Windows Management Infrastructure)

[alexandertsema]

I'm just curios if any of these libraries have been already implemented. If not what alternative can I use to retrieve hardware information with .Net Core? My target OS is Windows.

[danmoseley]

@karelz

[karelz]

What are the scenarios for using WMI on .NET Core? Is it something that would be valuable to have on .NET Core? Why? (please bear with my very little knowledge about WMI and how it is used in real-world projects)

[TheLastRar]

I've used WMI to find specific information about the computer's network adapters when dealing with OpenVPN Tap-windows and winpcap.

winPcap gives me the GUID of a device, which I use WMI to find the NetConnectionID (for the user to pick from).
Tap-windows, I search for adapters with a specific ServiceName / HardwareID to find what adapter belongs to it, then get the GUID to be able to use it.

[alexandertsema]

@karelz we are implementing server dashboard and using WMI to retrieve some data.

[maciek12305]

@karelz We've a monitoring software for cloud machines in asp.net that depends on System.Management. It would be pretty nice to have it in asp.net core, so that the application could be ported and hosted in an monolithic environment. The Application could run for example on an linux server but the main task would be to monitor windows machines over the network.

[budcribar]

We use WMI to get system info which we report back to the user of our hardware diagnostic program.

[louislewis2]

Just to transfer from the now closed issue https://github.com/dotnet/corefx/issues/3324
The lack of this API for us, is a total blocker and show stopper should the ASP.NET team go ahead with their current plans. In fact judging that the packages were just pushed to nuget, it seems that decision has already been made.

[karelz]

The decision has not been made AFAIK. The ASP.NET team is still seeking feedback and they pushed the change into master to give people chance to experience it first-hand. Please work with them on the main aspnet/Home issue. And raise awareness to all blockers, not just this one. (upvoting individual blockers helps)

This issue is valid regardless and we will prioritize it & consider it based on the feedback we get. The more votes, the better of course. Thanks!

[louislewis2]

Please indulge me for a few moments. It makes sense to a large degree that basing your efforts should be based on votes. However I do not think that should be the only motivation. I am certain that a great percentage of developers out there do not know all the dependencies that a package like JSON.NET has, if they had a concern about a missing API you might also only see one or two votes, however it is one of the widest used packages out there.

In turn not everyone is creating licensing servers and license managers for .Net, they simply use a package that solves their problem. So simply because we are maybe 1 or two people voting for this issue, the knock on affect is greater. The only way I can get more votes is to get all my customers to come and vote, though that would cause a panic which of course we are trying to avoid at all costs.

The potential problem that arose from the issue linked above, simply means that we have to let go of almost 3 years worth of work and start again on the old ASP.NET.

For solutions that I am either part of currently or have been in the corporate sector, which also make use of this API being voted for affects at least 8000 large companies, again those customers do not know the dependencies that we have taken, they just care if it works.

So I ask please to take this kind of scenario into account and not only base it on vote count.

[karelz]

Rest assured that we looked at and used all the data we could - we actively mined all nuget.org packages and we used the (smaller) application information/telemetry we have (see https://apisof.net).
We also worked with a few large partners inside and outside Microsoft to learn which dependencies are missing for them.
We also looked at transitive/indirect API usages as you point out above.

Most of those APIs are in 2.0 already. Note that some of the highly-used APIs were implemented, because of such high usage data (e.g. System.Data). The remaining important-but-not-so-highly-used APIs are in backlog, prioritized based on the usage data (and some which we do not plan to bring over at the moment like UI frameworks).
Voting system is our additional feedback channel which can point out things we might have missed from all the channels above.

If you think we missed something, voting is the best way to raise our awareness to it.
Obviously we can't/won't port libraries which have near-0 (transitive) usage and only couple of votes, until more evidence arises that our information about usage/votes is incorrect and there are more customers who would benefit from the APIs.

[shravan2x]

I agree with @louislewis2 on this, licensing is an important application of System.Management.

P.S. I had no idea Github reacts were considered this important here.

[karelz]

@shravan2x good point that we could/should mention it in repo docs - I made a note to describe prioritization / how upvoting helps.

I naively took it for obvious as there is no other way to tell which issue is how important. GitHub allows sorting by upvotes/*votes and by number of comments (other searches are irrelevant for prioritization purposes). Number of comments is weird metric to prioritize on - it takes just few vocal people to pump it up.
I don't know about any other simple way how to find out which issue matters to most people than using upvotes on top post.

Also note that having the most votes does not mean we will prioritize it. But you can be sure that we will take it into account.

[Hajisharifi]

We use WMI to modify Windows DNS Server and we have problem with The new ASP.NET Core 2.0
The Management, DirectoryServices, Drawing... support in NetStandard, please.
thanks.

[droyad]

@karelz Another use case, we (Octopus) use WMI to get all the child processes of the current process recursively so that we can wait on/kill them.

[lukasz-pyrzyk]

One more use case, BenchmarkDotNet uses WMI to detect active antivirus software and VM hypervisor.

[JosepBalague]

Hi folks,

Is System.Management.ManagementClass planned for a soon future?

I can't find it at https://github.com/dotnet/corefx/milestone/5

Cheers

[karelz]

The milestone of this issue is 2.1. Future means "not scheduled". See also how we use milestones.

AFAIK @AlexGhiondea is actively working with WMI team to figure out path forward here and the schedule. I guess we will be able to provide more details in next few weeks.

[JosepBalague]

Thanks for updating @karelz. I was confused about WMI milestone.

[almostjulian]

Any updates here @karelz ? Specifically, has there been a decision as to which library would be ported?

[karelz]

@AlexGhiondea @pjanotti planned to start the work this week. They should be able to provide more details about the scope of the work planned.

[louislewis2]

That is fantastic news! 👍

[pjanotti]

This work has started and we are on the first PR to get the code on the repo dotnet/corefx#24719

[karelz]

@pjanotti I updated area paths. I assigned the work to you and added "Fixes #xyz" into your PR top post to auto-resolve this issue when it is merged.

[danmoseley]

@louislewis2 @darkonejr @jmroyb @lukasz-pyrzyk @droyad @Hajisharifi @shravan2x @alexandertsema if any of you are willing to help add test coverage, we would welcome that, just coordinate with @pjanotti after his first PR is committed.