Frage

Ich versuche, ein Azure-Bereitstellungspaket mit CSPACK auf meinem Build-Server für Devfabric Deployment (CSRUN) auf einem Testserver zu erstellen.CSPACK kopiert pflichtbewusst die Web-Rolle-Binärdateien und -Dateien in das CSX-Paket, sondern erfordert auch einen 'SitephysicleDirectory' -pfad für jede Webrolle, die in eine "rorolemodel.xml" eingebettet ist.Dieses Verzeichnis muss bei der Paketzeit existieren.

Bei der Bereitstellung stellt CSRUN eine IIS-Site auf, die direkt auf den SitePhySicalDirectory-Pfad zeigt, und erscheint, dass die im CSX-Paket verpackten Web-Rollen-Binärdateien vollständig ignoriert werden.Unnötig zu erwähnen, funktioniert die Testbereitstellung auf einer anderen Maschine nicht.

Ich vermisse ich hier etwas?Warum kann cspack / csrun den physischen Pfad nicht in IIS in den CSX-Paket in IIS einstellen?Was ist der Zweck eines CSX-Pakets, wenn die verpackten Binärdateien nicht verwendet werden?Was machen SitephysicalDirectories in einer Produktion Azure-Bereitstellung?

War es hilfreich?

Lösung

I think part of this has to do with the addition of Full IIS. It used to be the case that your approot directory in Windows Azure was for both the RoleEntryPoint process and the IIS WAS Host (one in the same). However, with full IIS, you would have w3wp.exe running your web code and the WaWorker process executing your RoleEntryPoint.

The decision was made to effectively copy the entire website (which also has the WebRole.cs RoleEntryPoint) to a new directory and root full IIS there. As such, you will notice that your packaging for Web Roles actually contains a copy of your code twice. Once, for the website and once for the WebRole.cs RoleEntryPoint. Only your RoleEntryPoint is executed now out of approot. I don't remember all the technical reasons why this occurred, but it might have been easier/safer to copy the website out rather than risk missing a dependency.

Andere Tipps

I'm beginning to think the answer to all of those questions is "Because cspack/csrun are poorly-designed piles of garbage that should never have shipped". They seem to be built for Visual Studio support and nothing else.

Manually updating the RoleModel.xml file to set the physicalPath attribute to 'approot' (it's relative to the RoleModel.xml location) after packaging appears to be a viable workaround.

I would think that sitePhysicalDirectory should be set as the folder under AppRoot in your csx package, not the source of your web role binaries & files.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top