Comment utiliser ServerManager pour lire des sites IIS, pas IIS express, À partir d'une bibliothèque de classes ou comment les processus élevés gèrent-ils les bibliothèques de classes?
J'ai des méthodes utilitaires qui utilisent Microsoft.Web.Administration.ServerManager avec lesquelles j'ai eu des problèmes. Utilisez le code simple mort suivant à des fins d'illustration.
using(var mgr = new ServerManager())
{
foreach(var site in mgr.Sites)
{
Console.WriteLine(site.Name);
}
}
Si je mets ce code directement dans une application console et l'exécute, il obtiendra et listera les sites Web IIS express. Si je lance cette application à partir d'une invite de commande élevée, elle listera les sites Web IIS7. Un peu gênant, mais jusqu'à présent tout va bien.
Si à la place je mets ce code dans une bibliothèque de classes référencée et appelé par l'application console, il répertorie toujours les sites IIS Express, Même si l'application console est élevée.
Google m'a amené à essayer ce qui suit, sans succès.
//This returns IIS express
var mgr = new ServerManager();
//This returns IIS express
var mgr = ServerManager.OpenRemote(Environment.MachineName);
//This throws an exception
var mgr = new ServerManager(@"%windir%system32inetsrvconfigapplicationhost.config");
Évidemment, j'ai mal compris quelque chose dans la façon dont un processus "élevé" s'exécute. Tout ce qui s'exécute dans un processus élevé, même le code d'une autre dll, ne devrait-il pas être exécuté avec des droits élevés? De toute évidence non?
Merci pour l'aide!
3 réponses
Assurez-vous que vous ajoutez la référence au bon Microsoft.Web.Administration, devrait être v7. 0. 0. 0 qui se trouve sous c:\windows\system32\inetsrv\ Il semble que vous ajoutez une référence à Microsoft D'IIS Express.Web.Administraiton qui vous donnera ce comportement
Votre question m'a aidé à trouver la réponse pour PowerShell, donc si Internet cherche comment faire cela:
$assembly = [System.Reflection.Assembly]::LoadFrom("$env:systemroot\system32\inetsrv\Microsoft.Web.Administration.dll")
# load IIS express
$iis = new-object Microsoft.Web.Administration.ServerManager
$iis.Sites
# load IIS proper
$iis = new-object Microsoft.Web.Administration.ServerManager "$env:systemroot\system32\inetsrv\config\applicationhost.config"
$iis.Sites
Attention! En utilisant cette approche, nous avons vu des problèmes apparemment aléatoires tels que les exceptions" opération non prise en charge", l'échec d'Ajouter/Supprimer des liaisons HTTPS, l'échec de démarrer/arrêter les pools d'applications lors de L'exécution dans IIS Express, et d'autres problèmes. On ne sait pas si cela est dû au fait que IIS est généralement bogué ou à l'approche peu orthodoxe décrite ici. En général, mon impression est que tous les outils pour automatiser IIS (appcmd, Microsoft.Web.D'Administration, De PowerShell ...) sont déglingués et instable, en particulier sur différentes versions du système d'exploitation. Un bon test est (comme toujours) conseillé!
Le paquet normal Microsoft.Web.Administration installé à partir de NuGet fonctionne correctement. Pas besoin de copier des DLL système.
La solution évidente de la documentation officielle fonctionne également bien:
ServerManager iisManager = new ServerManager(@"C:\Windows\System32\inetsrv\config\applicationHost.config");
Cela fonctionne même si vous exécutez ce qui précède à partir du pool d'applications D'IIS Express. Vous verrez toujours la configuration de L'IIS "réel". Vous serez même en mesure d'ajouter de nouveaux sites, tant que votre l'application s'exécute en tant qu'utilisateur avec l'autorisation de le faire.
Notez, cependant, que le constructeur ci-dessus est décrit comme "Microsoft usage interne seulement":
Https://msdn.microsoft.com/en-us/library/ms617371(v=vs. 90).aspx