2010-02-09 86 views
4

Je travaille sur la configuration, la manipulation et le contrôle de IIS 6.0 et des versions ultérieures à l'aide d'une application web basée sur ASP.Net. Je considère WMI, ADSI, API géré comme mes options.Quel est le meilleur pour l'administration IIS dans ASP.Net: WMI ou ADSI ou API managée? et quelle est la différence?

J'ai un système Windows cible WIN2k3 ou versions ultérieures. Le choix de la langue est C# et l'application doit être construite en utilisant ASP.Net.

Cet article décrit chacune des méthodes, mais je suis un peu incertain sur diverses choses; http://learn.iis.net/page.aspx/283/provisioning-options-in-iis7/rev/1

J'ai les questions suivantes concernant ces options.

  1. Quel est le meilleur ou le plus puissant pour l'objectif indiqué? ADSI (System.DirectoryServices) ou WMI (Microsoft.Web.Management) ou API gérée (Microsoft.Web.Administratoion)? Corrigez-moi si je fais quelque chose de mal ici.

  2. Quelle option ou technologie est susceptible d'être prise en charge pour les versions ultérieures d'IIS?

  3. Quelle option a le plus de flexibilité et d'évolutivité? D'où puis-je trouver les ressources pour l'une des technologies suggérées/choisies?

Je suis moins susceptible de travailler sur II5.1 ou moins. Ainsi, la zone de compatibilité commence à partir d'IIS 6.0 et plus. L'application doit être construite en utilisant ASP.Net et le code non géré peut être utilisé si cela est inévitable.

Merci

Cordialement

Steve

Répondre

4

Pour IIS6, j'utiliserais l'espace de noms System.DirectoryServices qui est un wrapper géré autour d'ADSI. Je trouve cela plus simple à utiliser par rapport à travailler avec les fournisseurs IIS WMI.

Pour IIS7, et en tant que Precipitous suggested, j'utiliserais la nouvelle API d'administration de code géré IIS 7 (Microsoft.Web.Administration et al). Vous pouvez utiliser les composants de compatibilité IIS6 sur IIS7 qui conservent les anciennes API ADSI de style pour les consommateurs (mais qui sont un encapsuleur autour des nouveaux composants IIS7) et qui fonctionnent principalement. Cependant, vous rencontrez des problèmes avec les wrappers ADSI. Par exemple, ils ignorent les propriétés Mappage de gestionnaire (analogue à une carte de script IIS6) telles que preConditions qui, par exemple, autorisent la coexistence de plusieurs versions de définitions de mappage de gestionnaire ASP.NET dans le même site ou application.La couche de compatibilité ADSI crée des objets connus sous le nom de AboMapperCustom objets qui sont sous-optimaux dans leur configuration et ne sont pas conscients de ces nouvelles fonctionnalités. Avoir deux bases de code (une pour IIS6 et une pour IIS7) peut sembler beaucoup de travail, mais pour être honnête, ce n'est pas si mal. Je travaille pour un hébergeur, j'ai suivi cette voie, et nous avons décidé de maintenir l'ancien code IIS6 mais de recommencer à zéro avec IIS7.

4

Pour IIS 7 et plus, vous voulez probablement IIS Management API. Je suppose que vous avez déjà lu le MSDN comparison of administration technologies. En ne considérant qu'un seul projet, j'utiliserais l'outil que vous connaissez le mieux. Tout ce qui implique une manipulation directe de la métabase IIS nécessite un effort d'apprentissage spécifique. Étant donné la courbe d'apprentissage, j'ai choisi d'utiliser WMI. Il est utilisé largement au-delà de IIS et la maîtrise de ce dernier est un bon investissement. C# supporte son bien. Si vous connaissez un peu PowerShell, vous pouvez facilement l'explorer en utilisant l'objet "gwmi". Si vous utilisez WMI à partir de .NET, commencez par managed code generator.