Как я определяю, являются ли “IIsWebDirectory” или “IIsWebVirtualDir” Приложением ASP.NET?

Существует три способа, которыми можно приблизиться к этой проблеме:

• Простая Система. DirectoryServices
• Проанализируйте файл metabase.xml IIS
• Система. DirectoryServices и некоторые взаимодействующие с COM

Простая Система. DirectoryServices

Определение, ли IIsWebDirectory или IIsWebVirtualDir Администраторский объект IIS настроен, чтобы быть использованием приложения System.DirectoryServices один может иногда быть неочевидный бизнес из-за наследования свойства метабазы.

Например, когда Вы создаете 'приложение' обычно существует три набора свойств на IIsWebDirectory или IIsWebVirtualDir администратор метабазы возражает -

AppFriendlyName
AppIsolated
AppRoot

В метабазе Вы видели бы что-то как:

<!-- This is an application -->
<IIsWebVirtualDir   Location ="/LM/W3SVC/1/ROOT/MyApp"
    AccessFlags="AccessRead | AccessScript"
    AppFriendlyName="MyAppKev"
    AppIsolated="2"
    AppRoot="/LM/W3SVC/1/Root/MyApp"    
    >
</IIsWebVirtualDir>

Теперь Вы думали бы, что это будет столь же просто как проверяющий на присутствие этих трех свойств, и в особенности AppIsolated свойство, потому что это - свойство, раньше указывало на тип Изоляции приложения (незавершенный [0], из процесса [1], или объединил [2]) - и каждое приложение требует этого свойства. Как заметка на полях, на сервере, выполняющем IIS6, Вы только видели бы AppIsolated=0|1 если IIS работал в режиме эмуляции IIS5. Когда Вы создаете свои собственные приложения, необходимо всегда устанавливать AppIsolated=2 что означает сайт, или приложение будет работать в одном из Ваших пулов приложений (w3wp.exe).

Так или иначе... из-за наследования свойства метабазы, проверяющего на любое из этих трех упомянутых выше свойств, не гарантирует объект, который Вы исследуете, на самом деле приложение - ли это быть при помощи ADSI, WMI или DirectoryServices API. Даже если объект, который Вы проверяете, будет просто виртуальным каталогом (не приложение), то Вы все еще получите значения, возвращенные, потому что они были бы наследованы от родительского приложения.

Например, если /MyVdir виртуальный каталог (не приложение) расположенный в Веб-сайте По умолчанию, Вы все еще видели бы значение для AppIsolated, это вызвано тем, что это наследовано от IIS://Localhost/w3svc/1/root). То же применяется с AppFriendlyName и AppRoot свойства.

Подход, который я проявил здесь, должен был выдержать сравнение DirectoryEntry.Path свойство с AppRoot свойство на целевом администраторском объекте. AppRoot свойство, которое указывает, где конкретное приложение базировано. Это может быть удобно, если Вы исследуете администраторский объект IIS в глубине души в иерархии метабазы сайта, и необходимо знать, где ее приложение базировано в.

Так, скажите, что мне определили местоположение приложения в:

IIS://Localhost/w3svc/1/root/MyApp

... и скажите, что у нас есть экземпляр DirectoryEntry:

DirectoryEntry de = new DirectoryEntry("IIS://Localhost/w3svc/1/root/MyApp");

de.Path свойство было бы установлено на IIS://Localhost/w3svc/1/root/MyApp, AppRoot администраторское свойство объекта, de.Properties["AppRoot"].Value, был бы установлен на /LM/W3SVC/1/Root/MyApp. Все, что необходимо сделать, снимают изоляцию с продвижения IIS://Localhost и /LM строки и делают нечувствительная к регистру строка выдерживает сравнение. Если существует соответствие затем, объект в том пути является приложением.

Проанализируйте файл metabase.xml IIS

Существует иначе, что я использовал в прошлом, поскольку часть неисправного сервера восстанавливает задание, где у нас были файл метабазы, таблица базы данных vdirs и приложений, мы знали, что очень еще создали и не - сервер имел 1 200 веб-сайтов и множество виртуальных каталогов и приложений, прежде чем это появилось. В основном я загрузил целое metabase.xml файл в XMLDocument. Я затем использовал XPath для поиска присутствия AppIsolated припишите где Location attibute соответствовал пути, которым я интересовался.

Это - извлечение кода, который должен дать Вам общий jist идеи:

private XmlNamespaceManager _nsm = 
        new XmlNamespaceManager(new NameTable());
private XmlDocument _doc = new XmlDocument();
_doc.Load(@"c:\windows\system32\inetsrv\metabase.xml");
_nsm.AddNamespace("iis", "urn:microsoft-catalog:XML_Metabase_V64_0");

// lmPath could be build from the DirectoryEntry.Path property
string lmPath = "/lm/w3svc/1/root/myapp";

// Try as an IIsWebDirectory object
string iisWebDirectoryXPath = 
    String.Format(@"//iis:IIsWebDirectory[translate(@Location, 
            'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 
            'abcdefghijklmnopqrstuvwxyz') = '{0}']",
            lmPath);

mbNode = _doc.DocumentElement.SelectSingleNode(iisWebDirectoryXPath, _nsm);

if(mbNode != null)
{
    // We found an IIsWebDirectory - is it an application though?
    if (mbNode.Attributes["AppIsolated"] != null)
    {
        // IIsWebDirectory is an Application
    }
}
else
{
    // Is our object an IIsWebVirtualDir?
    string iisWebVirtualDirectoryXPath = 
        String.Format(@"//iis:IIsWebVirtualDir[translate(@Location, 
                'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 
                'abcdefghijklmnopqrstuvwxyz') = '{0}']",
                lmPath);

    mbNode = _doc.DocumentElement
            .SelectSingleNode(iisWebVirtualDirectoryXPath, _nsm);

    if (mbNode != null)
    {
        // Yes it's an IIsWebVirtualDir
        if (mbNode.Attributes["Path"] != null)
        {
            if(mbNode.Attributes["AppIsolated"] != null)
            {
                // And it's an application
            }
        }
    }
}

Парсинг сырых данных metabase.xml работы файла хорошо пока нет верхнего уровня, переворачивают приложений/виртуальных каталогов. Это вызвано тем, что обновления метабазы в оперативной памяти не сбрасываются к metabase.xml зарегистрируйте сразу. Я не рекомендовал бы делать это, я только приблизился к проблеме этот путь просто к целям системного восстановления.

Система. DirectoryServices и некоторые взаимодействующие с COM

Наконец существует третий путь (и вероятно самое простое), который Вы не можете тестировать правильно, если Ваша разработка, ПК не выполняет IIS6/Windows 2003 (я не имею машину XP в наличии, чтобы проверить, работает ли это с IIS 5.1). То, что Вы делаете, добавляет ссылка на библиотеку COM, названную 'Активное Расширение IIS DS Dll' (%systemroot%\system32\inetsrv\iisext.dll), это перечислено на вкладке COM в Visual Studio, Добавляет Ссылочный диалог. Когда Вы добавите эту ссылку, Visual Studio также автоматически разрешит и сошлется на зависимость, 'Активная Библиотека типов DS' (%systemroot%\system32\activeds.tlb). В Вашей ссылочной папке решения Вы будете видеть их перечисленный как 'ActiveDS' и 'IISExt'.

Используя библиотеку 'Active DS IIS Extension' мы можем протестировать, если администраторским объектом IIS в конкретном пути является на самом деле Приложение IIS путем выполнения следующего:

using (DirectoryEntry de = 
        new DirectoryEntry("IIS://Localhost/w3svc/1/root/MyApp"))
{
    // Cast our native underlying object to the correct interface
    IISExt.IISApp2 app = (IISExt.IISApp2)de.NativeObject;
    int status = app.AppGetStatus2();

    switch(status)
    {
        case 0:
            Console.WriteLine("It's an app but it's stopped.");
            break;

        case 1:
            Console.WriteLine("It's an app and it's running.");
            break;

        case 2:
            Console.WriteLine("No application found here.");
            break;
    }

}

Существует четвертый способ использовать WMI, но я только опустил пальцы ног в воду для некоторых довольно простых задач управления IIS/пула приложений.