I’ve been getting back into developing with Visual Basic lately. I’ve learned much of what I need to know in the past while in college; or so I thought. Much has changed since those days of Visual Basic 6. Everything is done a bit differently now using dot NET. Before, everything was Component Object Model components – and I really liked Visual Basic 6 for making it easier to develop those type of components. ActiveX controls, servers, hell – even application documents that ran inside of Internet Explorer was just easier to develop with VB than anything else. The Visual Basic runtime dll was in charge of running a lot of business infrastructure in the past.
Now a days its the mighty ubiquitious framework called Dot Net that drives business development. Made up of a huge collection of classes, dot NET is central to every language that runs on Microsoft. Even C++ developers write managed code these days. Instead of a runtime dll we get the Common Language Runtime, which interprets code written in any Microsoft language and churns out a bit of Intermediate Language that runs on a virtual machine. While its true that almost everything I am doing in VB now is a learning experience I see the value in this managed code base already; a lot just got easier.
One of the wisest decisions Microsoft has made recently was the release of the Community Edition of Visual Studio. A corresponding version of Microsofts flagship IDE used to cost a fortune in the past. Now, for the lone developer, its free to download and code with – great! All the code here is written and compiled with this IDE so download it and give it a try.
Getting system information by querying into the Windows Management Instrumentation system isn’t that difficult. Setting up the project to use the namespace was out of the ordinary – you have to explicitly add the reference to the System.Management namespace assembly to the project. There will be no help from the IDE with this. So you have to go to the Project properties page, click on References in the left column, hit the Add button, click on Assemblies->Framework in the left column, go down to the System.Management namespace and make sure the checkbox is checked. The same goes for the System.ServiceProcess namespace if you’re going to look at the running services as I have.
Basically, I’ve been working off of Microsoft code examples to get to where I am with this. To query WMI you set up and use a ManagementObjectSearcher class with your query and then iterate over the results. The sample application turns the query results into a List of string Dictionaries. Most of the time you’ll want to do a custom query to retrieve the specific information you desire instead of returning entire classes of information the way I have in the example application. Also, the queries take time more time than you might be used to, and this may become a problem. Using a separate thread to run your queries will improve response time. For instance I get a ContextSwitchDeadlock Exception if I do not run the Product query on a separate thread.
Why do the application at all? The one problem I have had is remembering the exact members of the different WMI classes I am querying for. The example app returns the entire class, or array of classes, with null values turned into empty strings for reference sake. It should be enough to get anyone started with building and testing the exact query they need.
There are dozens of scenarios where you would want to glean a bit of information from the System.Management namespace. Hopefully this example can help you on your way.