Comment déterminer si un “IIsWebDirectory” ou “IIsWebVirtualDir” est une application ASP.NET?

Question

J'écris actuellement une application C # asp.net pour me connecter à un serveur IIS et interroger le répertoire virtuel / les informations du répertoire Web.

Je suis en mesure de déterminer qu'il existe deux types de personnes avec lesquelles je devrais traiter est un "IIsWebDirectory". et "IIsWebVirtualDir".

Comment déterminer si elles ont été configurées pour être une "application" en C #?

Vous pouvez également afficher mes aventures dans C # et IIS ici et ici

MISE À JOUR

@Kev - J'ai pris les informations de votre réponse et développé la solution simple suivante pour vérifier si AppFriendlyName n'est pas défini sur "Application par défaut"

.

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...
            }
        }
    }
}

Answer 1

Vous pouvez aborder ce problème de trois manières:

• Ancien System.DirectoryServices pur
• Analyser le fichier IIS metabase.xml
• System.DirectoryServices et certains COM interop

Ancien ancien système System.DirectoryServices

Déterminer si un IIsWebDirectory ou un IIsWebVirtualDir un objet administrateur IIS est configuré pour être une application utilisant System.DirectoryServices seul peut parfois être une activité non évidente en raison de l'héritage des propriétés de la métabase.

Par exemple, lorsque vous créez une "application", trois propriétés sont normalement définies dans les objets admin de la métabase IIsWebDirectory ou IIsWebVirtualDir -

AppFriendlyName
AppIsolated
AppRoot

Dans la métabase, vous verrez quelque chose comme:

<!-- 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>

Maintenant, on pourrait penser que ce serait aussi simple que de vérifier la présence de ces trois propriétés, et en particulier de la propriété AppIsolated car il s'agit de la propriété utilisée pour indiquer le type d'isolation d'application (in process [0], out-of-process [1] ou pooled [2]) - et chaque application requiert cette propriété. En clair, sur un serveur exécutant IIS6, vous ne verrez que AppIsolated = 0 | 1 si IIS était exécuté en mode de compatibilité IIS5. Lorsque vous créez vos propres applications, vous devez toujours définir AppIsolated = 2 , ce qui signifie que le site ou l'application s'exécutera dans l'un de vos pools d'applications (w3wp.exe).

Quoi qu'il en soit ... en raison de l'héritage des propriétés de la métabase, la recherche de l'une des trois propriétés répertoriées ci-dessus ne garantit pas que l'objet que vous examinez est en réalité une application - que ce soit en utilisant ADSI, WMI ou . DirectoryServices API. Même si l'objet que vous vérifiez n'est qu'un répertoire virtuel (pas une application), vous aurez toujours des valeurs renvoyées car elles seraient héritées de l'application parente.

Par exemple, si / MyVdir est un répertoire virtuel (pas une application) situé sur le site Web par défaut, vous verrez toujours une valeur pour AppIsolated , car est hérité de IIS: // hôte local / w3svc / 1 / racine ). Il en va de même avec les propriétés AppFriendlyName et AppRoot .

L’approche que j’ai choisie ici consistait à comparer la propriété DirectoryEntry.Path à la propriété AppRoot sur l’objet admin cible. AppRoot est une propriété qui indique où une application particulière est enracinée. Cela peut être pratique si vous examinez un objet administrateur IIS au plus profond de la hiérarchie de métabase du site et que vous devez savoir où se trouve son application.

Donc, disons que j'avais une application située à l'adresse:

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

... et disons que nous avons une instance de DirectoryEntry :

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

La propriété de.Path serait définie sur IIS: // hôte local / w3svc / 1 / root / MyApp , AppRoot , admin La propriété d'objet, de.Properties [" AppRoot "]]. La valeur serait définie sur / LM / W3SVC / 1 / Root / MyApp . Tout ce que vous avez à faire est de supprimer les chaînes IIS: // Localhost et / LM qui précèdent, puis de comparer les chaînes sans tenir compte de la casse. S'il y a correspondance, l'objet de ce chemin est une application.

Analyser le fichier IIS metabase.xml

Il y a une autre manière que j'ai utilisée par le passé dans le cadre d'une tâche de reconstruction de serveur hors service dans laquelle nous avions le fichier de métabase, une table de base de données de vdirs et d'applications que nous savions avoir été créés et pas grand-chose d'autre: le serveur. 1200 sites Web et une multitude de répertoires virtuels et d’applications avant son apparition. En gros, j'ai chargé le fichier metabase.xml complet dans un XMLDocument . J'ai ensuite utilisé XPath pour rechercher la présence de l'attribut AppIsolated où l'attribut Location correspondait au chemin qui m'intéressait.

<