I am currently writing an C# asp.net application to connect to an IIS server and query the virtual directory/web directory information.
I am able to determine that there are that two types I should be dealing with is an ‘IIsWebDirectory’ and ‘IIsWebVirtualDir’.
How to I determine if they have been configured to be an ‘application’ in C#?
You can also view my adventures in C# and IIS here and here
UPDATE
@Kev – I took the information in your answer and developed the following simple solution to check to see if the AppFriendlyName is not set to ‘Default Application’
private void CheckIfApp(DirectoryEntry de) { if(de.SchemaClassName.Equals('IIsWebDirectory') || de.SchemaClassName.Equals('IIsWebVirtualDir')) { if (de.Properties['AppFriendlyName'].Value != null) { string friendlyName = de.Properties['AppFriendlyName'].Value.ToString(); if (!friendlyName.Equals('Default Application')) { //do something... } } } }
There are three ways you can approach this problem:
Plain old System.DirectoryServices
Determining whether an
IIsWebDirectoryor anIIsWebVirtualDirIIS admin object is configured to be an application usingSystem.DirectoryServicesalone can sometimes be a non-obvious business because of metabase property inheritance.For example, when you create an ‘application’ there are normally three properties set on the
IIsWebDirectoryorIIsWebVirtualDirmetabase admin objects –In the metabase you would see something like:
Now you would think that it would be as simple as checking for the presence of these three properties, and in particular the
AppIsolatedproperty because that’s the property used to indicate the Application Isolation type (in-process [0], out-of-process [1] or pooled [2]) – and every application requires this property. As a sidenote, on a server running IIS6 you would only seeAppIsolated=0|1if IIS was running in IIS5 compatibility mode. When you create your own applications you should always setAppIsolated=2which means the site or application will run in one of your application pools (w3wp.exe).Anyway… because of metabase property inheritance, checking for any of the three properties listed above doesn’t guarantee the object you’re examining is actually an application – whether it be by using the ADSI, WMI or
DirectoryServicesAPI’s. Even if the object you are checking is just a virtual directory (not application) you’ll still get values returned because they would be inherited from the parent application.For example, if
/MyVdiris a virtual directory (not application) located in the Default Website, you would still see a value forAppIsolated, this is because it is inherited fromIIS://Localhost/w3svc/1/root). The same applies with theAppFriendlyNameandAppRootproperties.The approach I took here was to compare the
DirectoryEntry.Pathproperty with theAppRootproperty on the target admin object.AppRootis a property that indicates where a particular application is rooted. This can be handy if you are examining an IIS admin object deep down in the site’s metabase hierarchy and you need to know where its application is rooted at.So, say I had an application located at:
…and say we have an instance of
DirectoryEntry:The
de.Pathproperty would be set toIIS://Localhost/w3svc/1/root/MyApp, theAppRootadmin object property,de.Properties['AppRoot'].Value, would be set to/LM/W3SVC/1/Root/MyApp. All you need to do is strip off the leadingIIS://Localhostand/LMstrings and do a case-insensitive string compare. If there’s a match then the object at that path is an application.Parse the IIS metabase.xml file
There is another way that I’ve used in the past as part of a dead server rebuild job where we had the metabase file, a database table of vdirs and apps we knew we’d created and not much else – the server had 1200 websites and a multitude of virtual directories and applications before it popped. Basically I loaded the whole
metabase.xmlfile into anXMLDocument. I then used XPath to look for the presence of theAppIsolatedattribute where theLocationattibute matched the path I was interested in.This is a extract of code that should give you the general jist of the idea:
Parsing the raw
metabase.xmlfile works ok as long as there isn’t a high turn over of applications/virtual directories. This is because in-memory metabase updates are not flushed to themetabase.xmlfile immediately. I wouldn’t recommend doing this, I only approached the problem this way purely for the purposes of system recovery.System.DirectoryServices and some COM interop
Finally there is a third way (and probably the simplest) which you may not be able to test properly if your development PC is not running IIS6/Windows 2003 (I don’t have an XP machine available to verify if this works with IIS 5.1). What you do is add a reference to a COM library called ‘Active DS IIS Extension Dll’ (
%systemroot%\system32\inetsrv\iisext.dll), it’s listed on the COM tab in Visual Studio’s Add Reference dialogue. When you add this reference, Visual Studio will also automatically resolve and reference a dependency, ‘Active DS Type Library’ (%systemroot%\system32\activeds.tlb). In your solution references folder you’ll see them listed as ‘ActiveDS’ and ‘IISExt’.Using the ‘Active DS IIS Extension’ library we can test if an IIS admin object at a particular path is in fact an IIS Application by doing the following:
There is a fourth way using WMI but I’ve only dipped my toes in the water for some fairly simple IIS/App Pool management tasks.