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.

Answer 1

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.

Answer 2

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. (eg 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.