How to publish

Hallo zusammen

ich möchte gerne mal eure Meinung zum Thema publishen einer Webseite lesen.

Wir haben eine ASP.Net (3.5) Applikation entwickelt, die wir auf einem Windows 2008 Server mit IIS 7.5 als Website laufen lassen.

Das Ganze funktioniert einwandfrei, da wir aber gleichzeitig relativ viele Benutzer online haben können, möchten wir so wenig Downtime wie möglich. Da wir bisher in eienr Testphase waren habe ich mein Publish jeweils mit der Option in Visual Studio gemacht. Und dabei die Einstellung "Delete all existing files prior to publish" verwendet. Mir ist klar dass wir so nicht in einen produktiven Modus wechseln können, da so immer die ganze Seite neu erstellt wird. Das kostet erstens beim kopieren, zweitens beim kompilieren und die Seite ist für eine Weile offline. Als weiterer Schwachpunkt sehe ich, dass auch alle Files gelöscht werden die in der Applikation selber hochgeladen wurden.

Wenn ich das Konzept richtig verstanden habe würde es reichen nur die geänderten Dateien zu kopieren. Somit wäre der Rest der Seite immer verfügbar?! Ich habe eine xcopy Lösung angedacht, aber möchte wie Eingangs geschrieben mal eure Meinung hören bzw. lesen. Ich bin mir auch nicht im klaren, ob man besser via SMB (FileShare), FTP oder sonst was publishen sollte.

In einem der Beiträge hier im Forum wird davon geschrieben, dass man sich 2 Seiten einrichten soll. und nach dem publishen umswitcht. Erscheint mir irgendwie ein bisschen nach einem Bastelansatz...

Danke für eure Kommentare

Grüsse

Marc

Hallo,

Erscheint mir irgendwie ein bisschen nach einem Bastelansatz...

Das was Du vorher vorgeschlagen hast, erscheint mir allerdings noch basteliger.
Wenn Du die Website während des Publish nämlich weiter verfügbar halten willst, riskierst Du immer Inkonsistenzen beim Zugriff, wenn z.B. von 2 voneinander abhängigen Dateien erst eine kopiert ist. Außerdem läufst Du Gefahr, daß Dateien, die sich gerade im Zugriff befinden, nicht aktualisiert werden können.

Gruß, MarsStein

Dateien, die von einem Benutzer hochgeladen wurden, gehören meiner Meinung nach auch nicht in den Applikationsordner, sondern ausgelagert.
Das würde auch das Problem, das Du erwähnt hast, ganz einfach beseitigen.

Ansonsten kann ich MarsStein nur zustimmen.

Meine Vorgehensweise ist:
IIS nutzt den Ordner APPNAME_PROD
VS published in APPNAME_PUBLISH
Anschließend benenne ich APPNAME_PROD in APPNAME_DATUM um und den APPNAME_PUBLISH in APPNAME_PROD.

Ergebnis: Offline-Time <1s

huhu,

ja, bei uns läuft es ähnlich wie bei Abt, mit dem Unterschied, dass wir den Pfad im IIS ändern. Dadurch kann man auch wieder zügig zur alten Version zurückkehren.

Aber, die Session kann troztdem sterben. Dann ist es egal "wie lange" der Update dauert.

.-)

Xynratron

Danke für eure Kommentare..

Und welche Option im VS wird bevorzugt verwendet?

1: "Replace matching files with local copies"
2: "Delete all existing files prior to publish"

Und gibt es auch die Möglichkeit vorzucompilieren? Ansonsten wäre ja nach dem Umbenennen die jeweils ersten Requests sehr langsam..

Gruss

Marc

Und welche Option im VS wird bevorzugt verwendet?

1: "Replace matching files with local copies"
2: "Delete all existing files prior to publish"

Variante 1 erübrigt sich bei meiner angesprochenen Methode, da keine Files im Ordner existieren.
Nichts desto trotz würde ich sowieso auf Variante 2 setzen, da ich das gefühl hab, dass der Vergleich bei Content-Files oft nicht funktioniert.

Und gibt es auch die Möglichkeit vorzucompilieren? Ansonsten wäre ja nach dem Umbenennen die jeweils ersten Requests sehr langsam..

Vorkompilieren geht über eine Post-Build-Action:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler -p "$(ProjectDir)." -v /$(ProjectName)
Der Vorteil hier ist auch, dass Fehler in ascx/aspx-Files direkt im VS-Debugger erscheinen und nicht erst beim Aufrufen der Seite

Und welche Option im VS wird bevorzugt verwendet?

1: "Replace matching files with local copies"
2: "Delete all existing files prior to publish"
Variante 1 erübrigt sich bei meiner angesprochenen Methode, da keine Files im Ordner existieren.
Nichts desto trotz würde ich sowieso auf Variante 2 setzen, da ich das gefühl hab, dass der Vergleich bei Content-Files oft nicht funktioniert.

Stimmt natürlich sorry

Und gibt es auch die Möglichkeit vorzucompilieren? Ansonsten wäre ja nach dem Umbenennen die jeweils ersten Requests sehr langsam..

Vorkompilieren geht über eine Post-Build-Action:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler -p "$(ProjectDir)." -v /$(ProjectName)

Hm aber dieses Script hilft mir nur fürs Kompilieren im Localhost richtig? Ich möchte nach dem Publshen auf den Server vorkompilieren..

huhu,

Hm aber dieses Script hilft mir nur fürs Kompilieren im Localhost richtig? Ich möchte nach dem Publshen auf den Server vorkompilieren..

ja, nee, möchtest du nicht. Wenn du im VS einen Publish ausführst, bekommst alles kompiliert und fertig zum kopieren auf den Server. Also musst du dann nur noch diese Dateien hoch/rüber kopieren, nichts mehr kopilieren.

😃

Xynratron

Ach so danke für die Erklärung.

Also ich fasse für alle (und vor allem für mich) kurz zusammen.

Ich habe in meinem Visual Studio ein Post-Build Event aufgesetzt:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler -p "$(ProjectDir)." -v /$(ProjectName)

Auf dem Server habe ich 2 Ordner:

MyPage

MyPage_Publish

Nach dem builden benutze ich die Publish action in VS und publishe meine Seite in den Publish Ordner MyPage_Publish auf dem Server.

Nach dem publishen benenne ich MyPage um in MyPage_xy und bennene anschliessend MyPage_Publish um in MyPage.

So verfahre ich für alle publishs.

Ist das so alles korrekt?

So ist zumindest mein Workflow, ja.
Kann die Vorgehensweise nur empfehlen.

Danke Abt 😃 Ich denke auch dass es Sinn macht. Ich schreibe mir jetzt noch ein kleines Exe dass mir das Umbenennen und archivieren abnimmt dann ist das ne ganz saubere Sache.

Grüsse

Marc

Hallo,

ja, nee, möchtest du nicht. Wenn du im VS einen Publish ausführst, bekommst alles kompiliert und fertig zum kopieren auf den Server.

Bzw. wenn Du direkt beim Veröffentlichen das Server-Verzeichnis angibst, wird schon alles vorkompiliert dort hingeschoben.

Die PostBuild-Aktion kannst Du Dir dann IMHO sparen.

@Abt:
Wo liegt der Sinn darin, im PostBuild (also nach dem kompilieren) den Compile-Vorgang nochmal anzuwerfen? Die Publish-Funktion nimmt einem das ja schon ab.

Gruß, MarsStein

Also ich sehe durchaus einen Sinn, beim Builden direkt die aspx/ascx/cshtml Files ebenfalls durch den Compiler zu jagen, um unter anderem auch die dort enthaltenen Fehler zu bekommen.
Da übernimmt die Publish-Funktion genau.. gar nichts 😉

huhu,

Ja und Nein, das liegt an der Option "Aktualisierbarkeit dieser vorkompilierten Site zulassen" respektive dem switch -u.

Folgendes "aspnet_compiler -p "$(ProjectDir)." -u -v /$(ProjectName)" erzeugt auch keinen Fehler.

Wenn Du diesen Schalter eh weglässt, dann kannst Du auch im Wizard diesen Schalter deaktivieren und du bekommst deinen Fehler.

😃

Xynratron

Das passiert aber nur beim Publish - nicht wenn ich den lokalen IIS via Debug nutze, richtig?

huhu,

naja, es ging ja um den publish - dachte ich jedenfals^^

Lokaler IIS zum debuggen nutze ich nicht, allerdings musst du doch auch beim Debuggen die "Website erstellen", damit du die aktualisierten dll's bekommst (ähh, wenn man mit mehreren Projekten arbeitet), oder? Da bekomme ich dann auch regelmäßig die Fehler angezeigt. Deswegen wäre ich nie draufgekommen, dass dieses Flag die Website published (erstellt) ohne dass ein Fehler in den ascx-Files ausgegeben wird 🤔

Ich finde das verhalten des aspnet-compilers eh seltsam.

🙂

Xynratron

Deswegen wäre ich nie draufgekommen, dass dieses Flag die Website published (erstellt) ohne dass ein Fehler in den ascx-Files ausgegeben wird

Nutzt Du dieses Flag nicht, werden die ascx-Files von Visual Studio komplett ignoriert. Die Fehler tauchen erst beim Aufruf durch die jeweilige Seite auf und werden dann im "yellow screen of death" in ASP-Manier angezeigt - und auch nur der erste Fehler der Auftritt. Folgefehler werden nicht gezeigt. Mit gegebener Konstellation tauchen aber alle Fehler brav in der Visual-Studio Error-Box auf und können auch direkt "angeklickt" werden.
Ich denke die Zeit, die das zweite Kompilieren benötigt, steht in absolut keinem Verhältnis zu der Zeit, die ich durch diese Variante spare.
Wenn ich nach Stunden bezahlt werde und keine Projektdringlichkeit hätte, dann wär das vielleicht ein Argument. 🙄