Partager via

Be careful when debugging Visual Studio 2005 created Web-Apps

  • Article

While fixing a bug (I have to do that every once in a while. It’s in the contract. I think), I needed to make use of the IsClientConnected property of the HttpResponse object in a WebService sort of project. After trying various things, I still could not make it return false so I decided to create a small test project with which to check.

 

Now, in VS2005, Microsoft added a feature to at least some of the versions of VS2005 where the environment spawns an extra Web Server that is used for the web-application you develop. The process that implements the web-server is called “WebDev.WebServer.Exe”. Basically, you are not using IIS, but you are using an ASP Web Server helper process. This is both really great and potentially bad all at the same time.

The advantages are that:

  1. IIS is not being used for other things - so that if you have a Source Control solution running on IIS, it will still work while you are debugging.
  2. It’s much easier to set up – no need for special configurations of IIS to make it debuggable etc. It just works when you try to run it.
  3. You can easily run multiple isolated web-servers when testing multiple web-applications – something that’s impossible to do with XP’s IIS (XP’s IIS supports only one site).
  4. It is probably somewhat faster – since the web-server is keyed towards development, various shortcuts can be made.
  5. The port number of the server changes every time you spawn the web-server – this may seem like a bad thing, but it’s actually pretty cool – it means that if you have any hard-coded parts in your system, you will discover them in short order.

 

However, there ain’t no such thing as a free lunch. There is one disadvantage and it can potentially be problematic.

Because it is not IIS that’s being used, the underlying behavior of the server can be different and that can cause undesired results.

 

For example, lets go back to my problem. I saw that IsClientConnected always returned true, so I decided to experiment. I created a small sample solution (client and server programs) and tried to find ways to make IsClientConnected return false. When I saw that no matter what I did, it kept always returning true, I launched my good friend Reflector and tried to see what IsClientConnected returns. As I was looking through the classes, I saw that ultimately, IsClientConnected returns the Connected property of a Socket. “That’s great!” I said to myself (I talk to myself often – one of the reason people in nearby offices have tried to assassinate me multiple times so far). All I need to do is read up on Socket.Connected and see what behavior to expect. Right?

 

Wrong! As my original app is working on IIS itself, it’s using a completely different set of classes (in this case, IsClientConnected ends up PInvoking a function called EcbIsClientConnected() ). Now, since these are two different functions, I cant hope to extrapolate IISs behavior.

 

So it’s back to the drawing board, trying to figure out WHY I can’t get IsClientConnected to work.