Es würde mich interessieren zu hören, wie Leute bedingtes Markup handhaben, speziell in ihren Masterpages zwischen Release- und Debug-Builds.
Das besondere Szenario, auf das dies anwendbar ist, ist die Verarbeitung von verketteten js und css Dateien. Ich verwende derzeit den .Net-Port von YUI compress, um eine einzelne site.css und site.js aus einer großen Sammlung separater Dateien zu erzeugen.
Ein Gedanke, der mir in den Sinn gekommen ist, war, den Abschnitt js und css include in ein Benutzersteuerelement oder eine Sammlung von Panels einzufügen und das <link> und <script> Markup abhängig vom Debug- oder Release-Status der Assembly anzuzeigen. Etwas in der Art von:
Das Panel ist semantisch nicht wirklich nett - das Wrapping von <script> -Tags in <div> ist ein bisschen eklig; Es muss einen besseren Ansatz geben. Ich würde auch denken, dass ein Block-Level-Element wie ein <div> in <head> ungültiger HTML-Code wäre.
Eine andere Idee war, dass dies mit web.config Abschnittsersetzungen behandelt werden könnte, aber ich bin nicht sicher, wie ich das machen würde.
Es gibt eine anständige Diskussion über Änderungen in den Einstellungen von web.config hier:
Verwendung verschiedener Web.config in Entwicklungs- und Produktionsumgebung
Hinweis: Sie stellen eine andere Frage, aber ich schlage vor, sich das trotzdem anzuschauen, weil es eine großartige Sammlung von Vorschlägen zum Umschalten zwischen Live- und Debug-Einstellungen ist und alle Antworten (IMO) einen gewissen Wert haben - nicht nur die am höchsten gewählte / angenommene Antwort.
Ich persönlich benutze eine Methode, die hier erklärt wird und denke, dass sie die flexibelste ist und auf alle Arten von Konfigurationsänderungen anwendbar ist, da sie dateibasiert ist, aber basierend auf der Lösung automatisch ausgetauscht werden kann Konfigurationen:
Im Wesentlichen führen Sie ein Pre-Build-Ereignis aus, um die Webkonfiguration mit einer anderen auf der Festplatte auszutauschen, wobei der Name der Lösungskonfiguration an den Dateinamen angehängt wird. Zum Beispiel habe ich web.config.release, web.config.debug und sogar eine web.config.neilathome.
Ich benutze dann genau die gleichen Methoden für bedingte Code-Bits, indem ich partielle Klassen erstelle und die Sachen, die sich zwischen meinen Lösungskonfigurationen ändern, in ihre eigenen Dateien setze. Zum Beispiel habe ich sync_timersettings.cs, eine partielle Klasse mit einigen Konstanten, die definieren, wie oft mein Update-Code einen Web-Service aufruft. Oder Sie könnten einfach alle Ihre Einstellungen in eine App.Settings-Datei einfügen und es so machen.
Ich finde es eine sehr flexible Lösung, es lässt mich Stücke von Javascript und CSS austauschen und solange Sie sich die Zeit nehmen, Dinge, die zwischen den Konfigurationen wechseln, in ihre eigenen Dateien zu legen, können Sie wahrscheinlich in einen Zustand wechseln kann in der debug-lösungskonfiguration debuggen und dann mit einem klick auf release und deploy umschalten.
Eine weitere Anmerkung:
%Vor%Antworten auf Kommentare:
Dies ist nur nützlich, wenn Sie über eine Konfiguration für die Debug-Lösung und eine weitere Konfiguration verfügen, bei der es sich um Ihre Live-Bereitstellung handelt. Es wird nicht funktionieren, wenn Sie (wie ich) eine Staging-, Release- und Neilonhislaptop-Lösungskonfiguration haben, da das DEBUG-Symbol nur gesetzt wird, wenn Sie das Debuggen aktiviert haben. Die Problemumgehung besteht darin, auf die Eigenschaftenseite Ihrer Webanwendung zu gehen und auf der Registerkarte "Erstellung" ein bedingtes Symbol für jede Ihrer Buildkonfigurationen anzugeben. IE, legen Sie Build-Konfiguration für die Freigabe und setzen 'Freigabe' in das bedingte Symbol auf dieser Registerkarte. Führen Sie das gleiche für verschiedene Build-Konfigurationen aus. Das dortige Bedingungssymbol ändert sich automatisch entsprechend Ihrer Build-Konfiguration. #ifbedingte Kompilierungsdirektiven funktionieren dann wie erwartet.
Bayard hat nach weiteren Informationen darüber gefragt, wie Sie die Markierung zwischen den Konfigurationen ändern können. Nun, Sie könnten verwenden, um die gesamte ASPX-Seite auszutauschen - have home.aspx.release und home.aspx.debug, aber es würde bedeuten, dass Sie in jeder Datei eine Menge Markup wiederholen mussten . Meine Lösung besteht darin, meiner Anwendung eine Teilklasse hinzuzufügen. Zum Beispiel hat meine 'ViewImage' Seite die folgende Klassendefinition:
%Vor%.. also habe ich einige Klassendateien mit der gleichen Signatur erstellt und sie 'ViewImage_titleset.cs.debug' und 'ViewImage_titleset.cs.staging' genannt:
%Vor%und
%Vor%.. das Aufrufen von SetTitle im Ereignis zum Laden der Seite für ViewImage würde den Titel ändern, abhängig davon, welche Build-Konfiguration vorhanden war. Dies funktioniert nur, wenn Sie die Seite programmgesteuert ändern.
Es ist besser, die obige Methode zur bedingten Kompilierung zu verwenden, um Code wie diesen zu ändern und die File-Swap-Methode zum Ändern von Nicht-Code-Dateien wie Bildern oder Web-Konfigurationen beizubehalten. Stellen Sie nur sicher, dass Sie die alternativen Dateien nicht für die Veröffentlichung festlegen.
Ich habe das gerade auf meiner Masterseite in meinem ASP.NET MVC-Projekt versucht und es hat funktioniert. Wenn ich im DEBUG-Modus die Entwicklungsversion von jQuery verwende und wenn nicht im DEBUG-Modus, verwende ich die verkleinerte Version von jQuery:
%Vor%Was die JS-Dateien angeht, verwende ich Web-Bereitstellungsprojekte , um die Web-App vorkompilieren. Nachdem der Build abgeschlossen ist, wenn die Konfiguration Release ist, verkleinere ich die JS-Dateien und ersetze die Dateien im Ausgabeverzeichnis. Dies alles geschieht mit MSBuild , da Web-Deployment-Projekte MSBuild-Dateien sind.
Tags und Links javascript asp.net msbuild compression