Using Cassini web server
My experience with Microsoft Cassini web server
Author: Sergey Sorokin
Last updated: September 2, 2010
Cassini is a lightweight web server software for Microsoft Windows capable of simultaneously serving multiple ASP.NET applications and web services and static HTML. Cassini is distributed with Visual Studio and not intended to be redistributed or run outside of Visual Studio. It is not supported by Microsoft as a standalone product. However, Microsoft included Cassini in other products (early versions of Microsoft CRM, for example). In March 2006 Microsoft released Cassini v2.1 sources under "shared source license" that explicitly says it can be used "for any commercial or noncommercial purpose, including distributing derivative works".
As of this writing, there are few distributions of Cassini based on the original Microsoft source code:
Also, there are some anecdotal evidences that Cassini binaries distributed with Visual Studio can be decompiled and (after some tweaking) successfully built for 32-bit and 64-bit platforms.
Comparing to IIS, Cassini has the following limitations:
While working on CSWorks, I was considering using Cassini. This guide is an attempt to digest different pieces of Cassini-related information found in the web (official announcements, bug reports, questions and answers, personal experiences) and present it in a more or less structured form.
If the project you are working on requires ASP.NET application or web service hosting, and none of the limitations above is a show-stoppers - think about using Cassini. If your product installation package contains a simple web demo that requires a web server, and you do not want your users to install IIS and ASP.NET worker process infrastructure on top of it just to see a few web pages hosted locally - Cassini may be a good option. It requires minimal installation effort, has small footprint and configuration takes seconds.
At least, this was my thinking when I started playing with Cassini :)
I used Cassini binaries that come with Visual Studio 2010 and built with .NET 4.0:
Running Cassini turned out to be simple:
WebDev.WebServer40.exe /port:8111 /path:"c:\Projects\My Web Application"
and voila: navigating to http://localhost:8112/Home.aspx takes me to my web project home page.
I included Cassini binaries in the setup of my webserver-based solution and made sure WebDev.WebHost40.dll is installed in the GAC. Now, the only problem is that somebody has to start Cassini before the user navigates to my simple demo web pages. Here is a simple script that uses PortQry utility to detect if Cassini is already running and listening on port 8111:
portqry.exe -n localhost -e 8111
if ERRORLEVEL=1 goto nolisten
echo Cassini is already running
goto end
:nolisten
start WebDev.WebServer40.exe /port:8111 /path:"c:\Projects\My Web Application"
:end
start http://localhost:8111/Home.aspx
All I had to do after that is to add a shortcut to the script to the Start menu under "My Web Application/Samples", and my web setup is done.
There are some "buts" though.
This is a minor thing and this is more of a question than a real problem. I did not investigate Cassini source code, so I do not know what was the reason for installing the assembly to the GAC. If it's just an easy way to get a full trust, my next question is: why does one need a full trust for a toy web server? Bottom line: I will feel a lot more comfortable with using Cassini by Microsoft if I have a good explanation for this GAC thing.
As of this writing, Visual Studio and Cassini run as 32-bit applications. If you try to host your 64-bit ASP.NET application using Microsoft's Cassini, you will get an exception. Your options are simple: either re-compile your ASP.NET application as 32-bit, or try using other Cassini distributions (see the list above).
Microsoft's Casini has a handy option /vpath that allows you to specify a virtual folder for your application. When I tried it and ran my application at http://localhost:8111/MyAppVirtualFolder/Home.aspx I got a problem: WebConfigurationManager.OpenWebConfiguration() throwing "Failed to map the path '/'" exception. The only workaround I have found is to run Cassini with elevated privileges, everything works fine then. This may be acceptable for testing purposes, but probably not an option when dealing with a customer. Again, it would be nice to have some explanation for this behavior.
Handy tool, but use it at your own risk.