Managing Windows Indexing Service with Visual Basic.NET Using COM
(Page 1 of 4 )
This article explains how to manage the Windows Indexing Service using the .NET framework. We will manage the Indexing Service using COM (together with .NET).
A downloadable file for this article is available
here.
The sample downloadable solution (zip) is entirely developed using Visual Studio.NET 2003 Enterprise Architect on Windows Server 2003 Standard Edition. But, I am confident that it would work with other versions of Windows (which support .NET 1.1) versions as well.
Comparing WMI and COM to work with indexing service using .NET
I already introduced you to the “Indexing Service” in my previous article named “Managing Windows Indexing Service with Visual Basic.NET using WMI.” In that article, I mainly focused on WMI to communicate with Indexing Service. It also introduced you to checking the status of Indexing service, installing, managing, and so on.
So, I will not be covering any of those concepts in this article. If you have any problem with Indexing service, I suggest you go through my previous article. In this article, I am going to focus on using COM to interact with Indexing Service, using .NET COM interoperability.
Can we manage/access “Indexing service” directly from within .NET (natively)? .NET natively doesn’t support access to Indexing service. So, we need to extend our .NET application to interact with either WMI or COM to manage/access the “indexing service.”
WMI is a good emerging technology from Microsoft for their support of WBEM (Web Based Enterprise Management). WMI gets enhanced day by day. For a complete understanding of WMI together with .NET programming, I suggest you go through my series “WMI programming using Visual Basic.NET” at this site.
Before proceeding further one should make a note that .NET interacting with COM makes the application “unmanaged.” This is a very important point to consider before we proceed further. If our application works within the limits of the .NET CLR (Common Language Runtime), it is considered “managed.” But COM operates beyond the control of CLR and thus becomes unmanaged. Even though COM existed before the evolution of .NET, .NET indeed supports COM interoperability. So, any exception thrown from within our application may not be only for .NET. It could also be from COM.
The next question would be, why did I choose COM to work with Indexing Service? Basically, Indexing Service existed even before the evolution of .NET and thus has been developed with COM/DCOM support (of course even with COM+ support). At the moment, Microsoft hasn't yet redesigned using .NET. So, I have no choice but to work with COM to interact with Indexing Service at the moment (apart from WMI, which I explained in my previous article).
Even though I can interact with Indexing Service using WMI and .NET natively, WMI didn’t expose too many features to really “penetrate” into all the features of indexing service. So, in this article, I will try to cover what I did in my previous article, but with COM interoperability (instead of WMI) and further dig the indexing service details to the maximum limit (where WMI could not be reached).
Next: Getting “Indexing service” status information with COM and VB.NET >>
More .NET Articles
More By Jagadish Chaterjee
/ 3 
