Ich war am Wochenende etwas grausam und habe beschlossen, das Projekt auf die 2.0-Plattform zu aktualisieren. Da VS2003 und 2005 nebeneinander existieren können, ist das Problem relativ einfach zu lösen. Installieren Sie die Pro-Version von 2005, öffnen Sie das Originalprojekt und führen Sie das Upgrade durch Der Assistent wird automatisch angezeigt. Das Projekt enthält 7 Unterprojekte. Jede Datei im Front-End-Webprojekt implementiert nur einen Aufruf der Hintergrundmethode und es werden keine erweiterten Methoden im Hintergrund verwendet Das Upgrade verläuft sehr reibungslos.
Zusammenfassend lässt sich sagen, dass die Projektdateien im Webprojekt gelöscht wurden. Es stellte sich heraus, dass bei der Kompilierung auch zwei unabhängige ASPX-Dateien berücksichtigt wurden. Ich habe es kompiliert, auf den Server hochgeladen und einen Fehler gemeldet. Später stellte ich fest, dass das neu kompilierte Projekt nicht über die DLL des Webprojekts verfügte, sie sich aber immer noch im Serververzeichnis befand. Das Ergebnis ist ein Durcheinander interner Referenzen. Löschen Sie die DLL des alten Webprojekts und alles ist in Ordnung.
Dann wollte ich den Veröffentlichungsmodus ausprobieren, um das Verzeichnis zum Veröffentlichen festzulegen. Es wurde tatsächlich alles im Webverzeichnis kopiert Der Kompilierungsprozess war sehr langsam. Nachdem die Kompilierung abgeschlossen war, wurden im bin-Verzeichnis eine Reihe von Dingen generiert. Ich dachte, dass das Kopieren dieser Dinge auf den Server die Notwendigkeit einer sauberen Kompilierung überflüssig machen würde. Es stellt sich heraus, dass der CSC-Prozess beim ersten Zugriff auf die Seite immer noch angezeigt wird. Nachdem die gesamte Website umgestellt wurde, gab es noch eine Menge CSC-Prozesse, aber der Kompilierungsprozess war etwas schneller als zuvor.
Ein weiteres schwerwiegendes Problem trat nach einer Weile automatisch auf, was dazu führte, dass es erneut kompiliert wurde. Auf dem Server wurde ein Fehler angezeigt, der besagte, dass ein Fehler im Prozess w3wp.exe aufgetreten sei Es? Nach Auswahl von „Abbrechen“ wurde w3wp.exe automatisch neu gestartet und eine neue Runde der Neukompilierung begann. Dieser Vorgang passierte dreimal und ich hatte solche Angst, dass ich schnell wieder auf Version 1.1 umstieg. Ich habe einen Blick in die Ereignisanzeige geworfen und eine Reihe nicht behandelter Ausnahmen gefunden, bei denen es sich im Grunde um Fehler mit leeren Werten handelte. Es ist seltsam, dass es in 1.1 kein Problem gab und der Code nicht geändert wurde.
Später habe ich einen Artikel gefunden (anscheinend hat ihn niemand auf Chinesisch erwähnt): http://www.eggheadcafe.com/articles/20060305.asp . Die Behandlung nicht behandelter Ausnahmen unterscheidet sich stark von der in 1.1 anders, 1.1 ignoriert es, es sei denn, es wirkt sich auf die Seitengenerierung aus. Und 2.0 führt dazu, dass der Prozess einen Fehler meldet, der sich direkt auf den Betrieb der gesamten Website auswirkt. Es klingt nach einem ernsten Problem, scheint aber vernünftiger zu sein, da Programmierer diesen Fehler sonst weiterhin ignorieren. Aufgrund dieses Problems ist jedoch auch die Unfähigkeit, die Website zu wechseln, ein ernstes Problem. Daher ist weiterhin eine reibungslose Übergangsmethode erforderlich. Wie oben erwähnt, besteht diese Methode darin, selbst ein HttpModule zu schreiben, um alle nicht behandelten Ausnahmen zu behandeln und Ausnahmeinformationen in Systemereignissen aufzuzeichnen, was für Programmierer bei der Verarbeitung von Vorteil ist. Außerdem finden Sie oben den Quellcode und den Download der Binärdatei dieses HttpModule, einschließlich der Demo-WebApp.
Heute habe ich endlich die Kompilierungsmethode der Version 2.0 vor der Bereitstellung verstanden. Es ist falsch, VS zum Veröffentlichen der Website zu verwenden. Sie müssen aspnet_compiler.exe zum manuellen Kompilieren verwenden, und der Kompilierungsprozess basiert auf den tatsächlichen Einstellungen der Website. Mit anderen Worten, Sie müssen den Inhalt des Webprojekts auf die Website hochladen, den Pfad der Website in IIS festlegen und dann aspnet_compile zum Kompilieren verwenden. Dieser Prozess kann die generierte DLL tatsächlich lokal ablegen diejenigen im Cache-Verzeichnis in WindowsMicrosoft.Net sind genau die gleichen wie diejenigen, die von csc.exe generiert werden, wenn der Benutzer tatsächlich auf die Seite zugreift. Nach diesem Schritt wird bei zweimaligem Besuch durch den Benutzer keine Kompilierungsaktion mehr ausgeführt.
So müde. Übrigens habe ich an eine nahtlose Umschaltmethode gedacht, bei der zwei Websites auf zwei verschiedene Verzeichnisse verweisen, von denen eines keinen Host-Header und das andere einen Host-Header zum Aktualisieren hat. Nachdem Sie die Website mit dem Host-Header aktualisiert haben, kompilieren Sie sie mit aspnet_compiler und wechseln Sie dann die Host-Header der beiden Websites, sodass neu besuchte Benutzer auf die neu kompilierte Website weitergeleitet werden und der Benutzer keine Verzögerung spürt. Aktualisieren Sie beim nächsten Mal einfach eine andere Website.
http://www.cnblogs.com/unfish/archive/2006/09/10/500230.html