Visual Studio 2005 enthält einen eingebauten Web Server, landläufig auch als Cassini bekannt (webdev.webserver.exe). Dies ermöglicht es ASP.NET Entwicklung durchzuführen, ohne dass der Programmierer lokaler Administrator sein muss oder den IIS installieren muss. Dies ist sehr hilfreich für kleine Anwendungen, Tests oder Demos. Wenn man allerdings in die einschlägigen ASP.NET Newsgroups schaut, häufen sich Fragen von denen viele folgenden Tenor haben: „Meine Anwendung hat in Cassini funktioniert, aber nicht im IIS“. Und – wen wunderts – diese Probleme sind alle Security-bedingt.

Cassini verhält sich in einigen Bereichen anders als IIS, und ist nun mal einfach nicht „der wahre Server“ auf dem Ihre Anwendungen später laufen werden. Versteht mich nicht falsch – Cassini ist ne tolle Sache für kleine Projekte, man muss sich allerdings über die Unterschiede im Klaren sein, die da wären:

Sicherheits-Kontext
ASP.NET Anwendungen unter IIS laufen mit einem least privilege Account, per default NETWORK SERVICE. Cassini gehostete Anwendungen laufen in dem Sicherheits-Kontext des aktuell angemeldeten Benutzers. Dies kann man leicht mit folgender Code-Zeile verifizieren:

Response.Output.Write(WindowsIdentity.GetCurrent().Name);

In Kombination mit der Tatsache, dass die meisten Entwickler mit Administrator-Rechten arbeiten, laufen diese Anwendungen als Administrator – etwas das Sie in Produktions-Umgebungen niemals tun würden (nein – würden Sie nicht :).
Da ist klar das so ziemlich alles funktioniert – doch nun kommt der magische Moment in dem die Anwendung auf IIS „umgezogen“ wird – und auf einmal gibt es Fehler über Fehler. Dies bedeutet, dass meist in den ungünstigsten Momenten (nämlich kurz vor dem Deployment) Fehler bereinigt werden müssen, die im schlimmsten Fall das Konzept der Anwendung in Frage stellen. Noch verheerender entschließt sich dann so mancher Administrator einfach den Sicherheits-Kontext des Produktions-Server auf LOCAL SYSTEM hochzusetzen…

Request-Mapping
In Cassini wird jeder eingehende Request zu der ASP.NET Runtime „durchgeschoben“, d.h. das auch .XML oder .MDF Requests die ASP.NET Pipeline durchlaufen und von den Authentifizierungs- und Autorisierungs-Einstellungen geschützt werden (z.B. FormsAuthentication). Dies ist unter IIS nicht der Fall!
IIS „kennt“ per-default nur die typischen ASP.NET Extensions (.aspx, .asmx, .ashx etc.), alle anderen Requests werden als statische Dateien behandelt und direkt von IIS an den Client zurückgeliefert (ohne das ASP.NET Sicherheits-Settings berücksichtigt werden). Ich habe darüber bereits hier und hier geschrieben.

Seien Sie sich über diese Unterschiede im Klaren, ansonsten kann es bestenfalls zu Problemen beim Deployment kommen, allerdings im schlimmsten Fall zu Sicherheits-Lücken.
Meiner Meinung nach sollte man so früh wie möglich (z.B. direkt nach dem Proof-of-Concept“) die Anwendung auf IIS portieren und testen. Andererseits kann es zu unliebsamen Überraschungen kommen.