GUYO


The next manged code library for WMI was discussed at TechEd this year and has popped up in a couple of webCasts. -- The WMI.Net 2.0 is supposed to provide writeable properties and invokable methods from managed code.

Is there an update on the release Beta program etc... --





Re: WMI.Net 2.0

Michel Baladi


As far as I know there's no beta program yet. There's a web cast on the technology available here: http://www.microsoft.com/events/webcasts/library/200606.mspx

At the end of the session, the Program Manager announces that the plan (at time of the presentation) was:

  • start a beta program after they are done with Vista (which was completed just a couple of weeks ago)
  • ship WMI 2.0 as part of next version of .NET Framework (code named "Orcas" (watch this space for "Orcas" info and downloads: http://msdn2.microsoft.com/en-us/vstudio/aa700830.aspx)

-Michel







Re: WMI.Net 2.0

Alain Lissoir

We are looking to ship this WMI enhancement in Orcas (WinFX 3.5).

This was mentionned during the MSDN Architecture Webcast June 2006 about .NET Application Instrumentation Using WMI.NET 2.0 (Level 200).

The first beta will be available during the course of next year with the Orcas CTP builds.

HTH.

/Alain







Re: WMI.Net 2.0

Zulfiqar

Is there any documentation on this new implementation

I have done little bit experimenting with it using the reflector tool and able to create a basic instrumented applicatoin with read/write properties and few methods.

The new API is much better than old one with a good fine-grained control over various aspects of WMI. I can see this model mimicing the .net configuration model so it would be an easy learning with this model.

My quick test shows tha this implementation is less fragile than old System.Management one especially in-terms successive registration/un-registration in WMI repository. It worked quite well.

I'm really looking forward to use this in some depth; I would be thankful If you could point me to some documentation on this

Thanks,





Re: WMI.Net 2.0

GUYO

You could always find a blogspace someplace and post your findings.. -- or I think it would be perfectly acceptable to post the results of your experimentation here ..




Re: WMI.Net 2.0

Alain Lissoir

If you install the Beta 1 of Orcas, you will find the documentation describing attributes (already available).

With the Beta 2 of Orcas, you will find code sample added to the documentation (summer)

HTH

/Alain






Re: WMI.Net 2.0

Gabriel GHIZILA

It seems like WMI.NET Provider Extension 2.0 documentation did not make it to MSDN by this time. People are working to push it into the right spot and there may be some articles/tutorials about how to use it given that it supports both coupled and decoupled providers, keys, singletones, references, method calls, so it may be a little bit confusing in getting everything right.




Re: WMI.Net 2.0

Vali_Ali

Is there an ETA for when sample code will show up on MSDN or anyweher else for using WMI.NET Extensions for building WMI providers More specifically, samples for how to provide for methods and writeable properties will be very useful. If this will take time, is there any other source for obtaining such sample code (has someone at MSFT written sample code that can be shared )

Thx,






Re: WMI.Net 2.0

Gabriel GHIZILA

I posted an article on MSDN on the writing of WMI.NET v2.0 coupled providers http://msdn2.microsoft.com/en-us/library/cc268228.aspx. It should take care of most questions regarding WMI.NET Provider Extension 2.0.

Gabriel





Re: WMI.Net 2.0

Vali_Ali

Thank you. That was really very good. I had some problems getting the sample up and running as getting a strong name for the provider kept giving errors (sn.exe kept giving Access Denied errors). Googling the error found some replies that helped to solve the problem in Vista. I have two quick follow-up questions:

Question 1: Do coupled providers have to be in GAC

Question 2: Will you be so kind to explain some primary differences between your current example and how to write decoupled providers, as well as the use of Singletons for decoupled providers.

Thx again for taking the time to write the article. A new web cast with updated contents for .NET 3.5 framework for WMI.NET v2.0 will be really useful as well when your time permits.






Re: WMI.Net 2.0

Gabriel GHIZILA

The system is simply loading the assembly based on its name. I guess the answer to your question is given by the documentation for Assembly.Load @ http://msdn2.microsoft.com/en-us/library/ky3942xh.aspx and "How the Runtime Locates Assemblies @ http://msdn2.microsoft.com/en-us/library/yx7xezcf.aspx. Given that many of those parameters are global for the loading application, i.e. WMI engined, is not recomandable to do it otherwise due to possible issues.

As is, the system allows generating the MOF at developement time still be able to load the library at runtime, after setup/deployment etc., with minimal set of steps to follow (compile the MOF and drop the assembly in GAC).

Decoupled providers have the life in their own hands so there will be no GAC.

There are basically two points in getting you a decouple provider from a coupled one, from the code writing perspective, starting from the article let's say. Obviously you need to take care of the overall behaviour given by the different ways the two different providers are loaded.

1. The WmiConfiguration attribute needs to be set on the assembly different:

[assembly: WmiConfiguration(@"root\YourSample", HostingModel=System.Management.ManagementHostingModel.Decoupled, IdentifyLevel=false)].

Please read Provider Hosting and Security @ http://msdn2.microsoft.com/en-us/library/aa392783.aspx to understand more about the IdentifyLevel.

2. The classes exposed to WMI need to be registered to show WMI there are alive and ready to answer. The simplest way to do that is to call at startup

InstrumentationManager.RegisterAssembly(yourAssemblyWithInstrumentedObjects);

That will scan your classes and make them ready for calls from WMI. The classes will automatically unregistered when you appdomain exits.

I will approach singletons in a different post, I have to refresh my memory.





Re: WMI.Net 2.0

Gabriel GHIZILA

The system is simply loading the assembly based on its name. I guess the answer to your question is given by the documentation for Assembly.Load @ http://msdn2.microsoft.com/en-us/library/ky3942xh.aspx and "How the Runtime Locates Assemblies @ http://msdn2.microsoft.com/en-us/library/yx7xezcf.aspx. Given that many of those parameters are global for the loading application, i.e. WMI engined, is not recomandable to do it otherwise due to possible issues.

As is, the system allows generating the MOF at developement time still be able to load the library at runtime, after setup/deployment etc., with minimal set of steps to follow (compile the MOF and drop the assembly in GAC).

Decoupled providers have the life in their own hands so there will be no GAC.

There are basically two points in getting you a decouple provider from a coupled one, from the code writing perspective, starting from the article let's say. Obviously you need to take care of the overall behaviour given by the different ways the two different providers are loaded.

1. The WmiConfiguration attribute needs to be set on the assembly different:

[assembly: WmiConfiguration(@"root\YourSample", HostingModel=System.Management.ManagementHostingModel.Decoupled, IdentifyLevel=false)].

Please read Provider Hosting and Security @ http://msdn2.microsoft.com/en-us/library/aa392783.aspx to understand more about the IdentifyLevel.

2. The classes exposed to WMI need to be registered to show WMI there are alive and ready to answer. The simplest way to do that is to call at startup

InstrumentationManager.RegisterAssembly(yourAssemblyWithInstrumentedObjects);

That will scan your classes and make them ready for calls from WMI. The classes will automatically unregistered when you appdomain exits.

I will approach singletons in a different post, I have to refresh my memory.