Before I begin, let me just clarify: the intent of this post is not to say you should run IIS instead of Cassini or vice-versa, but instead just to outline what one must be aware of if Cassini is chosen as development “host”.

What are the differences in using Cassini instead of IIS when developing ASP.NET applications?

Short:

• Only serves local requests
• Runs in user context
• All requests are parsed by ASP.NET

Longer:

Only serves local requests: It is not possible to access the application from remote machines. This makes it rather difficult (or tedius at least) fx. to debug authorizations when using Windows Authentication.

Runs in user context: An IIS normally runs as Network Service, i.e. a very well defined restricted account. When running the Cassini web server it runs in the context of the user starting Visual Studio. Most often this is a local administrator, which then gives the web application administrative priviliges when run using Cassini. A case where this has the direct cause of some hours of debugging.

A web application was developed that used the Report Viewer to view a report on a MS Reporting Services server. The report pulls data from a database located on another server that running the Reporting Service. The user/developer running the web application was dbo on the database using Windows Authentication. The connection string in the report was set to use Windows Authentication as well. Everything works like a charm. Then deploying to test, where database authentication was done using the machine account (i.e. Windows Authentication is performed on the NetworkService account – not a super method, granted, but lets ignore that for now) of the web server. In this case authentication fails on the Reporting Service to SQL server hop.

All requests are parsed by ASP.NET: This simply means, well, exactly that “All requests are parsed by ASP.NET”. This includes static items such as html, css, js, images, files, etc. Why does this matter? If you are thinking about rewriting URLs this will be obvious. For example you might create a rewrite rule based on HttpContext.RewritePath() (either directly or through a library, fx UrlRewriter.NET), mapping /Profile/JohnDoe to /Profile.aspx?user=JohnDoe. When run in Cassini this will work “out-of-the-box”, because the request for /Profile/JohnDoe is parsed by the ASP.NET engine and the mapping is performed. However when run in IIS the request will fail (for 2 reasons actually). First of all /Profile/JohnDoe will be translated to /Profile/JohnDoe/ and the default page will be tried served (fx. /Profile/JohnDoe/Default.aspx). This file does most likely not exist and IIS will probably serve a 404. Lets ignore this for a second and assume that it will try to serve /Profile/JohnDoe as a file directly. Since files without extension are not handled by aspnet_isapi.dll in a standard IIS installation, this IIS will try to serve the file directly, and again, since it does not exist IIS will probably serve you a 404 instead.

This was just a brief highlight of some of the differences (I have felt on my own CPU) between using Cassini and IIS when developing ASP.NET applications. Maybe more exist, I don’t know, but we can leave this as an exercise for the reader

ASP.NET · cassini · iis

1 comment

<< Paging large amounts of data in ASP.net / SQL2005

Custom Sorting using Compare method(s) >>