Nach einigen Stunden Config-Debugging möchte ich mal meine wesentlichen Informationen für Einstellungsarbeiten und Patch-/Hotfix-Installation geben, wenn man für folgendes Szenario eine Anwendung entwerfen möchte:
“Ein Silverlight-Client in der Cloud (Windows Azure)” nutzt einen ebenfalls in der Cloud gehosteten Webservice (basicHttpBinding)”
Betriebssystem: Windows 7
Webserver: IIS 7.5
Visual Studio: 2008 (SP1)
.NET: 3.5 (SP1)
CloudService: 1.1 (Feb. 2010)
Damit eine Windows-Azure Anwendung läuft, muss man über einen lauffähigen IIS verfügen. Als Entwickler nimmt man hierfür am besten den lokalen IIS auf dem eigenen Rechner. Für meinen IIS habe ich über die Funktion Control Panel->Programs and Features->Turn Windows features on or off folgende Einstellungen vorgenommen:
Wichtig ist die Aktivierung der “Windows Communication Foundation HTTP Activation” unter Microsoft .NET Framework 3.5.1.
Hotfix für WCF mit .NET Framework 3.5 unter Windows 7 oder Windows Server 2008 R2
Diese Hotfix-Sammlung http://support.microsoft.com/kb/981002/en-us muss installiert werden, damit die WCF Services in der obigen Konfiguration unter Windows Azure ohne Fehlermeldung arbeiten.
In der Web.Config seiner WebRole (von dem Windows Azure-Part des Projekts) muss der betroffene Service mit folgendem Behaviour definiert werden:
<behavior name="LoadBalancedBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true"/>
<useRequestHeadersForMetadataAddress>
<defaultPorts>
<add scheme="http" port="81" />
<add scheme="https" port="444" />
</defaultPorts>
</useRequestHeadersForMetadataAddress>
</behavior>
Info: Windows Azure Web-Dienste oder Webrollen laufen immer ab Port 81 und werden z.B. als http://127.0.0.1:81/Services/Service1.svc adressiert.
Bei der Generierung der Proxy-Klassen für den Silverlight-Client muss man dazu entweder eine zweite Visual Studio-Instanz aufmachen – damit erkennt Visual Studio den laufenden Service unter der Port 81-Adresse (ansonsten bekommt man die Adresse mit localhost:xxxxx des Cassini-Webservers) – oder man macht nach der Generierung der Proxy-Klassen ein Suchen/Ersetzen des http://localhost:xxxx/Services/Service1.svc durch http://127.0.0.1:81/Services/Service1.svc.
Ein weitere Falle, in die man rein treten kann ist, das der MIME-Type im IIS für .xap nicht definiert ist. Hier hilft dann folgendes:
To ensure solutions containing Silverlight clients work correctly in the development fabric, please ensure that the MIME type for the Silverlight .xap extension is configured correctly in IIS.
1. Open Internet Information Services (IIS) Configuration Manager and select the server to manage (usually the top-level item on the left side)
2. Double-click MIME Types on the right side
3. Add an entry to map the .xap extension to the application/x-silverlight-app MIME type
Um den Silverlight-Client debuggen zu können, kann man überprüfen, ob der ensprechende Haken in der Web-Rolle gesetzt ist:
If for some reason (say if you were doing Javascript debugging "you cannot debug Silverlight code and JavaScript code at the same time." or you didn't select "Enable Silverlight debugging when you created the Silverlight project) you disabled the Silverlight debugger, you can re-enable it on the Web tab of the Web Application project settings (lower right corner):
Mehr Informationen zum Thema Debugging von Windows Azure-Applikationen findet man übrigens hier: http://msdn.microsoft.com/en-us/library/cc838267(VS.95).aspx
Keine Kommentare:
Kommentar veröffentlichen