views:

8348

answers:

9

Currently our dev team set up all the websites they're working on in IIS on their local machine. We're thinking of switching to using the built in ASP.NET development server instead.

Is this a good idea? What are the pros / cons of using the ASP.NET dev Server? Are there any gotchas we should be aware of?

Thanks.

NB: Running on Win XP / IIS 5 / VS2005

Edit:

Didn't realise it was called Cassini.. More answers for Cassini v IIS here.

+16  A: 

There is nothing that the ASP.NET Dev WebService can do that IIS can't (You can set breakpoints etc, just attach the VS debugger to the ASP.NET runtime).

However, the ASP.NET Dev WebService does not represent a true production environment, and as such you can get caught by gotchas that you wouldn't expect when you deploy to production.

Because of that, I mandate that all development is done using IIS on a local machine. It doesn't take much work to configure a site in IIS.

FlySwat
Agreed. I've hit several gotcha's with running a project that way. You should always use local IIS.
EndangeredMassa
+1 absolutely, local IIS is the best for avoiding (and picking up before release) any problems
Darko Z
Jaap
Coming soon (or may be available by the time you read this) is IIS Express, bringing IIS 7.5 to non-admin users and allowing developers to use IIS 7.x features even when the host OS is XP. See http://weblogs.asp.net/scottgu/archive/2010/06/28/introducing-iis-express.aspx
Tim Trout
+1  A: 

I know at one point I had an issue with Authentication not working as expected on Cassini (built in development server)

Also, if you need to test things like ISAPI plugins (a re-writer for example) I'm not sure how that's done on Cassini.

The constantly changing port is also rather disconcerting to me. Also, for each web project in your solution it fires up another instance of a Casini server, and each one takes anywhere from 20 to 50 MB of memory.

I use IIS all the time, it's pretty easy to setup, and you guys are already doing that...

CubanX
Agree re. port numbers. We currently generate an RSS feed for links to our dev websites, don't think I'll be able to make it work with Cassini
Nick
On the "Web" tab of your web projects properties screen, you can specify a static port. For Web Site projects, this is in the standard property window.
JasonS
+14  A: 

It's a very good idea. Here are some reasons for:

  • You no longer need admin access to your machine for web development (it can still be helpful).
  • It's much easier to test a quick change and continue work, and faster iteration cycles are good.
  • It can simplify deployment and setting up development environments.
  • The XP version of IIS has limitation that are not present in the Server version that Cassini side-steps.

The only argument I know against is that there are a couple very rare edge cases where the Cassini built-in server doesn't exactly mimic IIS because you're using odd port numbers. I doubt you'll ever run into them, and using Cassini as the primary dev environment does not preclude developers from also having access to IIS on the machine.

edit
Forgot about url re-writing. You do need IIS for that. And an example of a limitation of the built-in XP IIS is that you are limited to one site in XP (can have multiple applications, but that's a different thing).

Joel Coehoorn
Cassini pipes every request to the ASP.NET runtime, IIS doesn't. Cassini cannot use ISAPI...IIS does. You can configure Visual Studio to launch your localhost on IIS when launching the app, and it will startup faster than loading cassini.
FlySwat
I'm with Joel on this one. Unless I bump into something that Cassini flat can't do (URL rewriting) I don't have any trouble with Cassini and find it very handy.
rp
It's interesting that an answer like this gets voted down. I think the opinion presented has merit--but even if I did disagree with it voting it down isn't the way do that.
rp
do you need admin to run iis?
rizzle
Just to run it, no. To use it for development, where you may need to adjust settings or add a virtual directory now and then, yes.
Joel Coehoorn
why is needing admin a problem? I have never ever worked for a company that didn't give me admin access nor would I... Also changes get picked up on IIS just as fast. Also how does a dev server simplify deployment? What odes the server have to do with deployment? Agreed on last point - non server IIS is always gimped in some way.
Darko Z
+1  A: 

I've used both methods and I prefer having IIS locally vs. using the built-in server. At very least you're more consistent with the final deployment setup.

Jeremy Bade
+3  A: 

I had to switch (back) to IIS for one project, because I needed to set some virtual directories which is not possible on the ASP.NET Development Web Server.

splattne
+1  A: 

Also, when using IIS 5.1, be sure to get JetStat IIS Admin, it adds functionality that is disabled out of the box on IIS 5, such as being able to setup multiple sites.

FlySwat
Thanks, will take a look, it'll save having to add code to deal with the VDirs.
Nick
+5  A: 

As I stated here: http://stackoverflow.com/questions/103785/what-are-the-disadvantages-of-using-cassini-instead-of-iis your developers need to be aware that Cassini runs as the local user, which is typically an admin account for developers. The development will be able to access any file or resource that their account can, which is quite different from what they will see on an IIS 6 server.

The other thing that's a pretty big gotcha is debugging web services is much easier using IIS and vdirs rather than separate Cassini instances.

Christopher_G_Lewis
A: 

I have run into the following limitations with the asp.net dev server:

  1. does not support virtual dirs. If you need them in your app, IIS seems to be your only choice

  2. Classic asp pages dont run in dev server. So if you have a mixed web app (like I have at my client right now), IIS seems to be the solution

  3. If you need an admin UI to configure settings, IIS works better

Of course IIS requires that you be a local admin.

A: 

The main issue I've run into with the dev server is SerializationExceptions with custom security principals stored on the thread context. Details here.

Rich Rodriguez