After trying some things in the IIS settings I wanted to change back to use the IWAM_* account. But for this I needed the password. I’ve searched and found some informations and tips to get the password that was used for the IUSR_* or IWAM_* accounts.
With „ASP.NET 2.0 AJAX Extensions 1.0“ (I love this name with two version numbers inside…) you can request a JavaScript Proxy for a web service with appending /js or /jsdebug to the web service path, like „http://my-server/my-service.asmx/js“.
When I deployed my application I’ve got the InvalidOperationException „No web service found at:“. When I called the web service without /js or /jsdebug the web service worked (at least the generated forms in the Browser where shown).
I’ve spent a lot of time ‚til I recognized the File my-service.asmx was not included in the deploy package. So without the /js appended the my-service.asmx file was not needed, the code from the compiled dll was executed directly, but when I added /js it needed the file.
Conclusion:
Don’t forget to add the .asmx files in the deployment of your ASP.NET AJAX Project!
Beim Entwickeln einer Web-Anwendung bin ich über eine Eigenart von ASP.NET 2.0 gestolpert. Beim Testen auf dem lokalen Rechner lief alles wie gewünscht. Nach dem Publishen der Webseite erhielt ich dann aber den Fehler:
Als Fehlerzeile war die erste Zeile mit der
-Direktive angegeben.
Nach einigem Suchen im Internet fand ich bei Peter Johnson den Blog-Eintrag Ambiguous match found, der mich auf das Problem aufmerksam machte:
Innerhalb meiner Seite hatte ich ein hiddenField mit der ID
und eine
Member-Variable mit dem Namen
. Diese beiden Variablen lebten während dem Entwickeln in friedlicher Koexistenz, nach dem Publizieren der Webseite vertrugen sie sich aber nicht mehr. Leider liefert das Visual Studio weder während des Entwickelns noch beim Publizieren irgendwelche Warnungen oder Fehler. Nachdem ich
in
umbenannt hatte lief dann alles reibunglos.
Stundenlang habe ich gesucht, bis ich den Fehler gefunden habe:
Unter bestimmten Umständen wurde meine Seite bei einem Postback erneut aufgerufen, aber mit
. Bis ich dann herausgefunden habe, dass es am
Tag liegt. Wenn das Attribut
nicht angegeben wird, wird das Tag image mit einem leeren
Attribut erzeugt, was den Browser dazu veranlasst, als Bild die Seite laden zu wollen. Dies erzeugte den nicht gewünschten Seitenaufruf. Nachdem ich ein leeres Bild als Standardbild angegeben habe, passiert dieser unerwünschte Seitenaufruf nicht mehr.
Wie Scott Guthrie in seinem Blog schreibt, erhält Atlas mit der Version 1.0, die Ende Jahr erscheinen soll, einen ofiziellen Namen (bzw. drei):
Mit der Version 1.0 wird es auch ofiziellen Support für die Bibliotheken geben.