C#

Using WMI with C#

Richard McCutchen — Fri, 25 Jan 2008 15:10:39 GMT

Recently I discovered the WMI (Windows Management Instrumentation) and was stunned at what it can do. Granted, the discovery was completely by accident, but I found it none the less. The WMI can mistify a lot of developers, especially new ones, so granted I was a little nervous and leery when I dove further into it, but what I found is that it can be an invaluable tool.

I jumped into learning the System.Management Namespace (which is where the WMI resides by the way) and discovered that WMI can save a developer tons of research time, clock cycles (as it is faster than other methods) and hair (from pulling it out looking for a solution).

When developing Windows applications, developers often need information a system, either local or remote, that although commonplace, can be very tough to get. There is using the remote registry, but I myself do not allow remote registry access as do many network admins. WMI is usually wide open on networks, assuming you have the privelidges necessary to query it, just as it is with remote registry querying/editing.

There is another reason WMI appeals to so many developers nowadays, its called WQL (Windows Query Language). WQL allows us a developers to query WMI providers using a SQL-like query language. If you know the provider classes and the fields available, then you can get the info very easily. Lets say, for instance, that you wanted to see the capacity, used space and free space available on a CD-ROM, you WQL query would look like:

"select * from Win32_LogicalDisk WHERE DriveType = 5"

You can then take that query, plug it into a ManagementObjectSearcher (a member of the System.Management Namespace), then use that to retrieve that particular information. In my example I populate the returned data into a Generic Dictionary<string,string> list, you may chose to do otherwise. But to retrieve the information I spoke about earlier, here is how you would find that information about the CD-Row:

public Dictionary<string, string> GetDriveInfo()

{

//dictionary object to hold the values

Dictionary<string, string> driveInfo = new Dictionary<string, string>();

//create our WMI searcher

ManagementObjectSearcher searcher = new ManagementObjectSearcher(@"select * from Win32_LogicalDisk WHERE DriveType = 5");

//now loop through all the item found with the query

foreach (ManagementObject obj in searcher.Get())

{

//create the used space by subtracting the size from the free space

double used = (double)obj["Size"] - (double)obj["FreeSpace"];

//add all the items to the collection

driveInfo.Add("FreeSpace", obj["FreeSpace"].ToString());

driveInfo.Add("Capacity", obj["Capacity"].ToString());

driveInfo.Add("UsedSpace", used.ToString());

}

//return the info

return driveInfo;

}

Notice how simple that was, and how ordinary it looks, it almost looks like you're querying a Database, but in fact you're querying a computer, either the system the application is running on, or a remote machine you have access to.

MSDN has a great writeup on WQL, what the DriveType values are you see me using in my queries, so dont let this scare you off, in the long run it will be quite the time saver when developing applications. Lets say you need to know how much free space is available on a network drive, before WMI and WQL you would have to rely on trying a remote registry query (testy at best, and it has to be open on the machine), but with WMI its a simple WQL query then a search.

The WQL Query for retrieving all network drives is:

"select name, FreeSpace from win32_logicaldisk where drivetype=4"

Notice I altered this query, unlike the first one I showed, in this one I only want to return the name of the network drive and the freespace it contains, I seen no need to return all the information if all I really wanted was 2 pieces. That would be the equivilent of "SELECT * FROM Table_Name" when all you needed was the record ID's. Once again we will plug this query into a ManagementObjectSearcher, this time using a SelectQuery, another member of WQL and the System.Management Namespace:

In this example I chose to populate a HashTable with the data returned, you, as with before, may chose to do it in a different fashion:

public Hashtable ReadFreeSpaceOnNetworkDrives()

{

//create Hashtable instance to hold our info

Hashtable driveInfo = new Hashtable();

//query the win32_logicaldisk for type 4 (Network drive)

SelectQuery query = new SelectQuery("select name, FreeSpace from win32_logicaldisk where drivetype=4");

//execute the query using WMI

ManagementObjectSearcher searcher = new ManagementObjectSearcher(query);

//loop through each drive found

foreach (ManagementObject drive in searcher.Get())

{

//add the name & freespace to our hashtable

driveInfo.Add("Drive", drive["name"]);

driveInfo.Add("Space", drive["FreeSpace"]);

}

return driveInfo;

}

So, as you can see the WMI can be an invaluable tool to learn, and in my opinion its worth the time to learn. WMI can save you time, it definately, as shown in the 2 methods, much simpler than trying a remote registry query, and I think as more and more developers discover and learn how to use WMI it will definately grow.

Introduction to Web Services in C#

Richard McCutchen — Sun, 30 Sep 2007 14:43:46 GMT

I posted a tutorial on my favorite programming forum </dream.in.code>, and thought Id go ahead and share it on my blog as well. One question I get all the time in programming communities, always by young, new programmers, is how to work with web Services in .Net. It was these questions that lead me to writing the tutorial I posted on Dream.In.Code.

I guess before you can show someone how to create and consume a Web Service, you need to ensure they know and understand what a Web Service actually is. The following is the easiest, simplest definition I've been able to come up for "What is a web service":

What is a Web Service you say? Well a Web Service is very general model for building applications that can be implemented for any operating system that supports communication over the web. To some this may sound a lot like a Web Site, but that is not the case, there are many differences between the two.

Here are the main differences between a Web Service and a Web Site:

Web Site has an interface - Web Service has no interface
Web Site is designed to interact with people - Web Service is designed to interact with other applications
Web Site is designed to work with web browser clients - Web Service is designed to work with any type of client or device

So as you can see, a Web Service and a Web Application have almost the same role, they just go about fulfilling that role in vastly different ways. A Web Service uses HTTP (Hypertext Transfer Protocol) and SOAP (Simple Object Access Protocol) to transfer data to and from the clients. Data sent to and from the Web Service is rendered into XML so the Web Service can read it, then it is sent back to the slient, which then renders the returned XML into the format it was expecting.

First, lets take a look at creating a simple Web Service. To do this, open Visual Studio, once it loads click File > New Website, when the New Project Dialog opens, select Web Service from the list of available projects, then for Location select either HTTP or File System (your own IIS), and lastly for Language select C#.

When the project is created it creates a Service.amsx and Sercive.cs file, you can either rename these, or delete and add new ones with the name of SampleService asmx and SampleService.cs.Now double-click on SampleService.cs to open the code file, then make sure you have the following references at the top of your class:

using System;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;
using System.Data.SqlClient;
using System.Data;
using System.Configuration;

If all the references aren't there, add the ones that are missing. Next, you will notice the first 2 lines are out of the ordinary, if you've never created a Web Service these two lines are downright weird:

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

Heres whats going on here, line 1 declares the Web Service's Namespace, and you might now be wondering Well whats a namespace? Well luckily theres an answer to that: Tempuri.Org defines a Web Service Namespace as:

Each XML Web Service needs a unique namespace in order for client applications to distinguish it from other services on the Web. By default, ASP.Net Web Services use http://tempuri.org/ for this purpose. While this suitable for XML Web Services under development, published services should use a unique, permanent namespace.

Your XML Web Service should be identified by a namespace that you control. For example, you can use your company's Internet domain name as part of the namespace. Although many namespaces look like URLs, they need not point to actual resources on the Web.

The next line of the first section of the Web Service uses the WebServiceBinding Method to create the Web Service's version of an Interface. After those 2 lines then you have your Initializer, which is, of course, the same as any other class. Here you can instantiate any objects you need used in each instance of the service:

public SampleService ()
{

//Uncomment the following line if using designed components
//InitializeComponent();
}

Nothing new there, now we get to jump into the heart of a Web Service, which is, of course, to make it do something, to perform some service. When you create your methods, if you want them to be visible from the client thats consuming the service, you have to add the [WebMethod()] Attribute to it. This tells the service that its ok to expose that method to the client which is consuming it.

Since this is just a simple, basic Web Service it only has a single method, just to show you what can be done with a Web Service. Since this service is communicating with a Sql Database, it needs access to the System.Data.SqlClient Namespace. There are other Namespaces the service will use, we listed them above, but lets take a closer look at them:

System Namespace - Base class for all Namespace's
System.Web - Provides classes and interfaces required for server/browser communication
System.Web.Services - Provides all the functionality required to create a Web Service
System.Web.Services.Protocols - Provides all required protocols the Web Service needs to transfering data
System.Configuration

Since the is an example for a beginner with Web Services, our sample service has but a single method in it, GetAllUserInfo. This method is designed to:

Query a SQL Server
Retrieve all the information for all users in the system
Populate a DataSet using a SqlDataAdapter
Pass the DataSet back to the client.

Now lets take a look at the code for this method:

/// <summary>
/// Here we're going to create a [WebMethod] that
/// can be called from an aspx page, then return
/// a populated DataSet to the calling aspx page
/// </summary>
/// <returns>A dataset popululated with the Members informaiopn</returns>
[WebMethod]
public DataSet GetAllUserInfo()
{
    //Build the SqlCilent Objects we need
    SqlConnection conn = new SqlConnection(Utlilties.GetConnectionString("WebService_Conn"));
    SqlCommand cmd = new SqlCommand();
    ///SqlDataAdapter to populate our DataSet
    SqlDataAdapter adapter = new SqlDataAdapter();
    ///DataSet to hold the users information
    DataSet dsInfo = new DataSet();
    ///String to hold our stored procedure
    string query = "RetrieveUserInfo";
    ///try...catch block to handle any unhandeled exceptions
    try
    {
        //set our SqlCommands Objects
        cmd.CommandText = query;
        cmd.CommandType = CommandType.StoredProcedure; //tell it its a Stored Procedure we're executing
        //if using inline SQL change the CommandType to Text
        //cmd.CommandType = CommandType.Text;
        //set its connection property
        cmd.Connection = conn;

        //now handle the connection state
        ///of our SqlConnection Object
       /// Utlilties.HandleConnectionState(conn);
        //set the SelectCommand Property
        ///of our SqlDataAdapter Object
        adapter.SelectCommand = cmd;
        //now we fill our DataSet
        ///using the Fill Method of
        ///the SqlDataAdapter
        adapter.Fill(dsInfo, "Members");
        //return the DataSet to the calling aspx page
        return dsInfo;
    }
    catch (Exception ex)
    {
        System.Web.HttpContext.Current.Response.Write(ex.Message);
        return null;
    }
    finally
    {
        ///put everyting in the finally section
        ///of the try...catch block you want executed
        ///whether theres an exception or not, in this
        ///case we want to close the connection no
        ///matter what happens
        ///close the connection
      /// Utlilties.HandleConnectionState(conn);
    }
}

This operates as explained. It opens a connection to our database, retrieves all the user information from the users table, then populates a Dataset ans returns the DataSet to the client. Notice the [WebMethod()] attribute at the start of the method, this says that any client that consumes this Web Service will have access to that method, and the data it returns.

Believe it or not, our Web Service is complete. Now with a Web Service in a production environment will have much more meat on its bones, but for our demonstration, this is really all we need to show how a Web Service works. Next question people ask is "Ok, we have this service out there on our server, how do we access it and use it?". Well thats a good question, to use the Web Service we just created you need a consumer, a client that will connect to the service and gather the data.

In this example we will create an ASP.Net Web Application that will consume our Web Service, then display the returned data in a GridView Control. So, in your Solution Explorer window, right-click on the very top node, the solution name, then select Add > New Project. Once the New Project Dialog opens, you will this time select ASP.Net Web Site as the project type, once again either HTTP or File System for the Location and C# for the Language.

When the project is created is automatically adds a Default.aspx, and Default.aspx.cs. It's the CS file we will be doing the programming in. You always want to keep your presentation seperate from your logic, thats why Microsoft offers both files for a single page in .Net.

Since this is just a sample, open Default.aspx in Design Mode, add a table to the page, then a GridView to the page. The GridView is what we'll use to display the data returned from our Web Service. You are now finished designing our ASPX page for consuming our Web Service. Now open Default.aspx.cs, and make sure you have the following references at the top of your class:

using System;
using System.Data;
using System.Configuration;
using System.Collections;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;

Those are the only references you will need for this example. Now we need to add a reference to the Web Service we just created, to do this:

Right-click on the project name
Select Add Web Reference
Once the dialog box opens select Web Services in this solution
Once it finds your service, click on its name
Wait for it to connect to the Web Service (when this happens the TextBox in the right-hand side of the dialog will be populated with the word localhost
Click the Add Reference button

NOTE: Before clicking the Add Reference button I renamed my from localhost to Sample

Now we have a reference to our Web Service and can starting using it. In our ASPX page we have a single method, BindGrid(), and this method will:

Create a referene to our Web Service
Create a new DataSet
Set our DataSet to the GetAllUserInfo method in our Web Service (remember, it returns a populated DataSet)
Bind the returned DataSet to our GridView

The code for this method is:

private void BindGrid()
{
     //create our DataSet to hold the member information returned
     DataSet dsMembers = new DataSet();
     //create our WebService object
     WebServiceConsumer.Sample.SampleService sample = new WebServiceConsumer.Sample.SampleService();
     //set our DataSet to the GetAllUsers Method of our web service
     dsMembers = sample.GetAllUserInfo();
     //now we need to set some properties for our data grid
     gvMembers.AutoGenerateColumns = true;
     gvMembers.DataSource = dsMembers.Tables["Members"].DefaultView;
     gvMembers.DataMember = "UserID";
     gvMembers.DataBind();
}

Simple enough isnt it? Now to use this, we will call this method from our Page_Load Event in our page, and that looks like this:

protected void Page_Load(object sender, EventArgs e)
{
BindGrid();
}

Believe it or not, thats it, thats all the code required to consume our Web Service and sisplay the returned data. The one difference in our BindGrid method is this:

WebServiceConsumer.Sample.SampleService sample = new WebServiceConsumer.Sample.SampleService();

That is where we create the reference to our Web Service, then we can use sample.WhateverMethodIsThere for utilizing the methods in the Web Service, instead of typing the long name out.

I am also providing a links to the Source Code for this example, all I ask is that you keep the header intact.

Thank you for reading, and I hope you found this helpful