Differences in behaviour between IIS and the ASP.Net Web Development Server?

Question

During development, I usually test ASP.Net applications using the Web Development Server (sometimes called Cassini). Occasionally, when I publish to a real IIS environment, I notice that the application behaves differently.

So, what are the differences between the way that production IIS servers and the ASP.Net Web Development Server behave? I don't mean differences in feature sets (clearly IIS has lots of features that are not present in WDS), but differences in the way they handle ASP.Net.

BTW: There are a few differences noted in the responses to this question, but I am sure there must be more.

Lugsail

There are lots of similar questions (see list on the right side), e.g: #1988522 – Bedad

Indeed - and I have linked to one of the more helpful ones in my question. Nevertheless, I'm looking for a more comprehensive answer than I found elsewhere. – Lugsail

Shouldn't this be community wiki? – Tyra

Answer 1

Some differences might be:

• You can't use virtual directories while working with cassini. This might lead to unexpected behaviour when deploying for the first time, due to missing folder permissions. (e.g. You have a /image/ directory on your local machine, but in the IIS /image/ is the virtual directory pointing elsehwere)
• Some third party assemblies (like ComponenArt Web DLL) cause problems with specific port issues. It's best to develop with the IIS to minimize compability problems on deploying.
• The trustlevel of the target IIS might be lower that your development settings, this might result in malfunctioning, depending on what you do with the IIS, like reading the Uptime.

Antitoxic

Your last point is a bit of a red-herring. The trust level whether working with Cassini or IIS on the same machine will always evaluate to the same. When you deploy to production it won't matter about whether you developed your application on Cassini or IIS because trust level isn't controlled by the server. – Vesicant

sorry citronas - you are mistaken on point 1, /v:"/" is the default, but you can specify any depth of vdir you like, both from the web properties page and from the command line. Point 2 doesn't really make sense. 'some people say'. And number 3 has already been covered. I have no choice but to --. Cheers. – Monosymmetric

@code poet: 1) I did not know that. Thanks for telling me. 2) I didn't want to name specific controls, but you leave me no choice ;) The ComponentArt Web DLL has this kind of issue. Happend once for me that I had into problems before deploying because it hadn't tested with cassini before. Since then, I only use IIS for developing – Antitoxic

Damn. My previous comment makes no sense: Happend once for me that I ran into problems before deploying because it hadn't tested with IIS before. – Antitoxic

Answer 2

Some things I have picked up here and elsewhere:

• The security context in which the respective servers run ASP.NET apps is different. For the Dev Server, this is the current user's account. For IIS, this is the context of the special user (ASPNET or NETWORK SERVICES) that typically has limited privileges.

• For a Web Site, the Development Server subjects static files (images and style sheets etc)to ASP.NET authorization. However, IIS serves static files without using authorization rules.

• The Development Server doesn't support SMTP, so you can't send emails directly from this server.

• The Development Server doesn't support HTTPS.

• There is a difference in the way the two servers handle paths that contain "//". The Dev server is reportedly being more forgiving.

• The Dev server randomly chosen port rather than the standard HTTP port 80.

Lugsail