Im Handumdrehen ist es 4 Jahre her, dass Microsoft die .net-Plattform auf den Markt gebracht hat, und .net hat auch Upgrades von 1.0 über 1.1 auf 2.0 erlebt. Aufgrund der Attraktivität verschiedener überlegener Funktionen von asp.net 2.0 und der vs 2005 IDE sind alle damit beschäftigt, 2.0 zu lernen und das Projekt für die Entwicklung auf vs 2005 zu aktualisieren. Tatsächlich können viele Projekte jedoch aus verschiedenen Gründen nicht auf neue Versionen aktualisiert werden. Mit der Zeit wird das Problem der Projektpflege alter Versionen immer problematischer. Obwohl .net noch vor nicht allzu langer Zeit geboren wurde, reichen 4 Jahre aus, um eine große Anzahl von Projekten anzusammeln.
Ich habe ein mit vs.net 2002 entwickeltes Projekt, das aus verschiedenen Gründen nicht aktualisiert wurde (hauptsächlich, weil das Projekt vor der Veröffentlichung von vs.net 2003 eine Weile gut lief und andere asp.net-Programme auf dem Server nicht möglich waren). zur Anpassung an die Sicherheitsanforderungen von .net 1.1).
Als die Entwicklungsplattform des Unternehmens aktualisiert wurde, wurden vs.net 2002 und vs.net 2003 gleichzeitig auf dem Computer installiert, wodurch die Wartung verschiedener Versionen des Projekts vorübergehend gelöst wurde. Später hat das Projekt den Wartungszeitraum überschritten und wurde lange Zeit nicht aktualisiert. Mein Computer wurde ebenfalls neu installiert und vs.net 2002 wurde vollständig entfernt. Aber im Jahr 2005 forderten die Kunden alle ein bis zwei Monate Änderungen, und sie mussten schnell sein. Die Kunden waren so begeistert, dass sie auch nach der Wartungszeit Änderungen vornehmen mussten. Aber hier kommt das Problem. Ohne vs 2002 kann es nicht kompiliert werden.
Es ist sehr mühsam, .net Framework 1.0 auf dem Computer zu installieren und csc manuell aufzurufen, um den geänderten Code zu kompilieren. Das Projekt enthält viele Referenzen und das Schreiben der Befehlszeile ist sehr kompliziert. Dies ist besonders schmerzhaft, wenn das Projekt über viele Ordner verfügt. Ich habe auch den Test gemacht und ein Programm zum Kompilieren geschrieben, aber ich war faul und habe es nie bemerkt.
Heute muss ich das Programm erneut ändern, und plötzlich fiel mir ein, dass ich das Src-Attribut der @Page-Direktive einmal sehr früh verwendet hatte (im Jahr 2002 verwendete asp.net sein eigenes Kompilierungsmodell anstelle von CodeBehind). der vs.net-IDE. Auf diese Weise kann der Code veröffentlicht werden, ohne ihn in eine DLL zu kompilieren. Beim Zugriff auf die Site kompiliert asp, net automatisch die ASPX-Datei und die .aspx.vb-Datei. Es gibt zwei Hauptnachteile dieser Methode: 1. Die Codedatei (.vb) muss auf dem Server veröffentlicht werden, 2. vs.net IDE unterstützt sie nicht. Wegen des zweiten Problems habe ich es aufgegeben und vergessen. Jetzt mache ich mir Sorgen, dass ich das Programm nicht kompilieren kann. Solange der geänderte Code wirksam werden kann, werden andere Mängel nicht berücksichtigt. Auf jeden Fall wird der gesamte Quellcode auf dem Server veröffentlicht. Ich habe der @Page-Direktive ein Src-Attribut hinzugefügt, das denselben Wert wie das CodeBehind-Attribut verwendet und auf die Codedatei verweist. Ändern Sie dann den Code in der .vb-Datei. Aktualisieren, die Änderungen werden wirksam und die Wartung ist abgeschlossen. So cool. Das werde ich von nun an tun. Da die vs.net-IDE dies nicht unterstützt und auf MSDN erwähnt wird, wissen möglicherweise nicht viele Leute, dass .net über dieses Kompilierungsmodell verfügt. Teilen Sie es jetzt. Wenn jemand das gleiche Problem hat wie ich, können Sie auch versuchen, Src zur Seite hinzuzufügen. Sobald der Code geändert wurde, wird er nicht wirksam um Tools zum Kompilieren zu finden.
Zusammenfassung: Viele Leute, mich eingeschlossen, kompilieren das Programm lieber in eine DLL, die sich eher wie eine veröffentlichte Software anfühlt. Tatsächlich ist die Methode „den gesamten Quellcode auf dem Server zu veröffentlichen und den Code zur Laufzeit vollständig zu kompilieren“ sehr gut und vereinfacht zukünftige Wartungsarbeiten erheblich. Viele Unternehmen führen Projekte für Kunden durch, bei denen es nicht unbedingt erforderlich ist, den Quellcode vor Kunden zu verbergen. In diesem Fall bringt die Verwendung dieser Methode enorme Vorteile für zukünftige Wartungsarbeiten. Unabhängig davon, ob .net n-mal aktualisiert wird oder ob die entsprechende Version der Entwicklungstools auf Ihrem Computer installiert ist, müssen Sie sich keine Sorgen machen kümmere mich um alles.
Hinweis: Alle Versionen von asp.net unterstützen diesen Kompilierungsmodus, aber die IDE von vs.net 2002 und 2003 unterstützt ihn nicht und kann die Entwurfsansicht nicht öffnen. Die neu veröffentlichte IDE von vs. 2005 unterstützt diesen Kompilierungsmodus. Bei Verwendung des Src-Attributs ist das CodeBehind-Attribut nicht mehr erforderlich, es wird jedoch empfohlen, es weiterhin beizubehalten. Es kann Ihnen auch helfen, wenn Sie plötzlich zur Berechnungsansicht zurückkehren müssen. Das Inherits-Attribut ist nicht erforderlich, es wird jedoch dringend empfohlen, es nicht zu löschen, da es ein Ereignis gibt, wenn Sie das Ereignis direkt in die Steuerdeklaration der ASPX-Datei binden (z. B. OnClick="...."). Fehler ohne das Inherits-Attribut.
Quelle: cwbboy BLOG