This morning, I tried to start up Visual Studio, and I got the following message in a dialog box:
The application cannot start
This KB article (http://support.microsoft.com/kb/306905) gives 7 possible causes, listed by likelihood. I tried the fix for Mxsml3.dll, but it didn’t solve the problem.
Here’s a little context. Last Friday, I was trying to install Team Server (build) on my desktop, but apparently it’s not compatible with Vista. So this morning, when Visual Studio didn’t start, I figured it was because something got messed up during the Team Server (build) installation. So, here’s the fix:
I put in my Visual Studio installation DVD and chose the Repair/Re-install option. Every few minutes, I tried to run Visual Studio–usually that’s a no no–and after about 4 minutes into the repair script, the error message went away and Visual Studio started up just fine. I then decided to gamble and cancel the repair/re-install, betting that the installer wouldn’t really rollback the broken DLL. I was correct.
This saved me a lot of time, since un-installing/re-installing Visual Studio usually takes many hours to complete.
I ran into an interesting problem today. I have a custom build task that executes when building a Team project in Microsoft’s Team Foundation Server. It creates a custom build number that follows the major.minor.build.revision format commonly used for Microsoft assemblies. However, this build task had been writing the build date (YMMDD) for the build part, and it was writing the actual build number (e.g. 221) for the revision. So a complete buld number might be 2.0.61215.203, meaning that the build happened on 12/15/2006 and it was the 203rd time we built that project. Pretty cool, eh?
Well, when I tried to build it this morning (1/2/2007), I got the following error:
Properties\AssemblyInfo.cs(32,12): error CS0647: Error emitting ‘System.Reflection.AssemblyVersionAttribute’ attribute — ‘The version specified ‘2.0.70102.203′ is invalid’
After a little digging and brainstorming with another developer, we rediscovered that each part of the full build number is actually treated as an unsigned 16-bit integer. The max value for such an integer is 65534. So, of course 70102 would cause an error.
In our case, the “minor” part is not important, so we decided to push the year over to get the following: 2.7.0102.203. Once this fix was made, our builds were successful.
Cool bug, eh?