Wir haben derzeit einen Prozess, der dazu führt, dass ASP.NET-Websites erneut bereitgestellt werden. Der Code ist selbst eine ASP.NET-Anwendung. Die aktuelle Methode, die schon eine ganze Weile funktioniert hat, besteht darin, einfach alle Dateien in einem Ordner zu durchlaufen und sie über die Dateien im Webroot zu kopieren.
Das Problem, das aufgetreten ist, besteht darin, dass Dateien gelegentlich verwendet werden und daher nicht kopiert werden können. Dies war in der Vergangenheit zeitweilig bis zu dem Punkt, an dem es keine Rolle spielte, aber auf einigen unserer verkehrsreicheren Seiten passiert es jetzt die meiste Zeit.
Ich frage mich, ob jemand einen Workaround oder einen alternativen Ansatz dafür hat, an den ich nicht gedacht habe. Derzeit sind meine Ideen:
Weiß jemand, was der beste Weg ist, dies zu tun, oder wenn es möglich ist, # 2 zu machen, ohne die Veröffentlichungsanwendung als Benutzer auszuführen, der Administratorzugriff hat (Bereit, ihm spezielle Privilegien zu gewähren, aber ich würde lieber aufhören Kurz vor dem Administrator)?
Bearbeiten
Klärung der Infrastruktur ... Wir haben 2 IIS 7-Webserver in einem NLB, die ihre Webroots von einem gemeinsam genutzten NAS ausführen (um es deutlicher zu machen, sie verwenden genau die gleiche Webroot auf dem NAS). Wir machen viele Bereitstellungen, bis zu dem Punkt, an dem jeder Ansatz, den wir nicht automatisieren können, nicht realisierbar ist.
Was Sie tun müssen, ist ein vorübergehender Stopp, dass IIS eingehende Anfragen für diese App verarbeitet, damit Sie die neuen Dateien kopieren und dann erneut starten können. Dies wird zu einer kleinen Ausfallzeit für Ihre Kunden führen, aber wenn Ihre Website nicht geschäftskritisch ist, sollte das kein großes Problem darstellen.
ASP.NET hat eine Funktion, die genau auf dieses Szenario abzielt . Grundsätzlich läuft es darauf hinaus, eine Datei namens App_Offline.htm im Stammverzeichnis Ihrer Webanwendung zu erstellen. Sobald die Datei vorhanden ist, wird IIS den Arbeitsprozess für Ihre App beenden und alle verwendeten Dateien entfernen. Nachdem Sie Ihre Dateien kopiert haben, können Sie die App_Offline.htm-Datei löschen, und IIS startet glücklich wieder.
Beachten Sie, dass IIS seinen Inhalt als Antwort auf alle Anforderungen an Ihre Webanwendung bereitstellt, während diese Datei vorhanden ist. Sei also vorsichtig, was du in die Datei legst. : -)
Eine andere Lösung ist die programmgesteuerte IIS-Verwaltung.
Dann können Sie Ihr neues / aktuelles Web in ein alternatives Verzeichnis kopieren und dann den IIS-Stamm Ihrer Webanwendung in dieses alternative Verzeichnis umschalten. Dann ist es egal, ob Dateien im ursprünglichen Root gesperrt sind. Dies ist eine gute Lösung für die Verfügbarkeit der Website.
Allerdings erfordert es einige Erlaubnis tuning ...
Sie können es über ADSI oder WMI für IIS 6 oder Microsoft.Web.Administration für IIS 7 tun.
Über Ihre 2. Beachten Sie, dass WMI keine Administratorrechte erfordert wie ADSI. Sie können Rechte nach Objekten konfigurieren. Überprüfen Sie Ihre WMI-Konsole (MMC).
Da Sie bereits Lastenausgleich zwischen zwei Webservern durchführen, können Sie:
Sie können auch versuchen, den Zeitstempel von web.config im Stammordner zu ändern, bevor Sie versuchen, die Dateien zu kopieren. Dadurch werden die Anwendung entladen und die verwendeten Dateien freigegeben.
Sofern Sie nicht manuell eine Zugriffsnummer für eine Datei auf Ihrem Webserver öffnen, behält IIS keine Sperren für Ihre Dateien bei.
Versuchen Sie, andere Dienste herunterzufahren, die Ihre Dateien möglicherweise sperren. Einige Beispiele für gängige Dienste, die genau das tun:
Wir hatten den gleichen Server (2003) und das gleiche Problem. Bestimmte DLLs wurden gesperrt und die App_Offline.htm in die Website Root diddly für uns gesetzt.
Lösung:
Dateiberechtigungen!
Wir haben einen Webdienst verwendet, der unter dem Netzwerkdienstkonto oder dem IIS_WPG-Konto ausgeführt wird, um Updates für die Website bereitzustellen. Daher benötigte es Schreibzugriff auf alle Dateien. Ich wusste das bereits und hatte bereits vor einiger Zeit die Berechtigungen für das Verzeichnis festgelegt. Aber aus irgendeinem seltsamen Grund wurden die erforderlichen Berechtigungen nicht für diese eine Problem-DLL festgelegt. Sie sollten die Berechtigungen nicht nur für das Verzeichnis, sondern auch für die Problemdatei prüfen.
Wir haben Benutzern von Network Service und IIS_WPG Lese- / Schreibzugriff auf das gesamte Web-Stammverzeichnis gegeben, und das hat unsere Datei in Verwendung, Datei gesperrt, Timeout und Zugriff verweigert Probleme gelöst.