Side by side issues

August 18, 2004

This is something of a dying art, since Microsoft is doing their level best to pretend that .NET 1.0 doesn't exist any more-- but here are a few key utilities you'll need when running .NET 1.0 and 1.1 side by side.

Each website on an IIS server must be bound to a specific .NET runtime; this GUI utility lets you quickly bind a website to the .NET version of your choices. Bear in mind that as a developer you're very likely to be running the crippleware version of IIS which only allows a single website, and at most 10 connections (40 with registry hack) to that website. But on Server 2000 or Server 2k3, you can have as many websites as you like.

The language changes between .NET 1.0 and 1.1 are minimal, and in most cases you can actually load a VS.NET 2003 project in VS.NET 2002 without any problems, and vice versa. This solution conversion utility allows you to convert a VS.NET solution back and forth between 2002 and 2003 formats at will. You may want to check out the author's blog as well; not many posts, but some are rather interesting:

.NET - Blacklisted APIs - "The functions you were never meant to call"

  1. Screen.GetWorkingArea() - Use instead, Screen.PrimaryScreen.WorkingArea (For some reason, GetWorkingArea takes 25 ms to complete)
  2. Application.DoEvents() - The call of the devil.
  3. Control.RecreateHandle() - There's no reason why you should ever need to use this.
  4. Application.EnableVisualStyles() - Use a manifest. .NET 1.1 just doesn'timplement thisfunctionright.
  5. NativeWindow.ReleaseHandle() - Contains some nasty bugs.
I had no idea high school seniors were this smart. :)

Also, this won't affect many of you, but any .NET assemblies instantiated via an <OBJECT> tag in HTML will always bind to the latest version of the .NET runtime on the machine. There is no concept of side by side for assemblies loaded this way. Shocking, but true. I would strongly advise against building object tag "deployed" .NET apps for anything non-trivial.

Posted by Jeff Atwood
2 Comments

Two comments:

1. It would seem to me to be less than perfect code to assume the application is running on the primary screen. Therefore, I suspect SystemInformation.WorkingArea is more appropriate to determine the screen dimensions.

2. Why on earth (or heaven... or hell) do you say DoEvents is the call of the devil???? How else can I get a form to paint during program startup, instead of leaving a nasty white, half-painted frame while data is being read in? What's wrong with yielding for one cycle?

Todd Beaulieu on December 11, 2005 12:47 PM

regarding #2, Application.DoEvents() is something you really do want to avoid when possible. If your form is not painting right away because you are doing something intensive like reading a file, or hitting a DB or webservice, then you should run the intensive logic on a separate thread and leave the UI thread alone. If this is a simple "for yourself" kind of app, then no need to get fancy and Application.DoEvents() is fine. But for anything that is a professional app, you need to make proper use of UI and non-UI threads. In .NET 2.0 the easiest way to do this is using the BackgroundWorker component.

With that said, there are some special cases where Application.DoEvents() is OK to use. For me, I use it in my splash screen when an app is going through its various loading steps (so the progress bar will repaint). But other than that I avoid it and any web service/DB/file IO is done on background threads which notify the UI thread when they complete.

Andres Becerra on August 23, 2007 6:50 AM

The comments to this entry are closed.