A few suggestions:
1 - The ability to start and stop a site. As in IIS, I may need to keep a site's configuration stored, but have the site be disabled for one reason or another (releasing resources, disabling access, etc.)
2 - Virtual directory support would be wonderful. For example, if I have a script library that I share between sites, but do not want to have multiple copies for each site.
3 - Ability to export/import site settings between machines. It's not hard to add new sites in Web Server Explorer, but would be even easier if each site's settings could be exported to an XML file, so that I could potentially include it in the solution or source control for team members to import.

The product looks pretty good overall, and I think it will work ou well for my development team. Thanks for your efforts.

Thanks. For clarification on virtual directories, I wasn't talking about running my app in a virtual directory. Rather I'd like to add other virtual directories to my app. For example, when running on a Windows 2003 server with IIS 6, there is usually a virtual directory for aspnet_client on each site. Or many sites may share a common javascript library or CSS library. It would be poor app design on my part to require a copy of these libraries to be placed in each site if they are all supposed to be the same and kept in sync.

That aside, I disagree and believe that even a "properly written" application can have expectations on its path relative to the webroot. It may not be ideal for some situations, such as drop-anywhere-and-run portability, but it is often the most logical choice for other applications, such as very apps with ASPX and ASCX files at multiple directory "levels", especially when these apps have one single "home" and will never be moved to another location. Think of www.microsoft.com as an example -- it's not moving to www.microsoft.com/somedirectory, so it would be silly to require extra effort from the developers and designers to make it directory agnostic. Maybe not the best example, but it illustrates my point.

For item 3, I'll have to look into that. Without being extremely familiar with this product, I would think that I would look into registering the app in command line mode over running it in command line mode at debug time. The security context may be an issue, but what I am more concerned with for our dev team is the accessibility of the application. In other words, do I have to be debugging to run the application? I would think that with the "better yet" portion of your answer I would have to be actively debugging in order to keep the app running. Correct? If not, then that definitely sounds easiest.

Thanks

I have to say that Virtual Directory is a reseaonable requirement.I event consider that an Application should stand as a Virtual Directory,instead of individual Port/Root.

Represent only my own opinion.

- Applications/Virtual Folders;
- Logging;
- NTLM Authentication;
- ISAPI support;

/*
- SSL;
- Compression;
- CGI support;
*/

Last 3 features I have commented out are not necessary according your 80/20-rule,in my own opinion. We would rather regard Cassini as a portable Web Server,for real world,in cheap environment---sometime is not meaning power hardware&OS,only by the consideration of maintaining cost. For example,some of our customers can hardly carry some of full-duty IT technology supporting,just for one server,by some little but,well necessary feature. Windows XP is the most environment they are familiar with,this will need Cassini or something like that very much.

As for developing or debug environment in another hand,for we professinal person,Windows 2003/IIS is not so hard to get.I think we can live without other Web Servers excepting IIS,here is not the real place of Cassini.