A few Extra Thoughts after three days with VS 2005 Beta 1


Last week I spent three days app building. (Day 1, Day 2, Day 3) My goal was to port the VSCmdShell project to Whidbey, finish some feature work, fix bugs, and release both a VS 2003 and VS 2005 0.8 version of the add-in.  I accomplished most of what I was looking to do.  Due to a SxS bug, that I’ll explain, the 0.8 release is going to be delayed a couple of more days.  It’s OK, you don’t have the beta yet now do you?  Oh, you use VS 2003... well… you can wait.  Anyway, here are my thoughts on how this release is shaping up to tide you over. 




Without the bugs you wouldn’t know its beta.  It will hit you when you run into your first gotcha that will have you googling for a clue because the help documentation is incomplete and the help search has some interesting visual bugs that you are not using final release quality software.  I think it’s better than VS 7.0 beta 1.  Having spent a good chunk of the last milestone as a QA lead I can let you know that the QA teams have written full test plans, but only had time to automate a “less than full” set of those tests.  This means that a lot of scenarios may have only been covered once or twice manually for this release and have not yet been through the testing rigors that will accompany the final release.




Shim? You don’t need no Stinkn’ Shim! Not having to use a shim control to write a managed tool window add-in rocks!  It just would have been nice if the wizard generated code built the first time around. 




Not-so Missing Docs: The documentation that was there feels cleaner than in previous releases and they also make it very easy to tell what has changed from the 1.1 to the 2.0 release.  I found the documents that described the new 2.0 extensibility features to be very well done to just the right level of detail.




The “Anti-Bugger”: After debugging with VS 2005 for three days I can’t go back.  The new visualizations are very cool.  For example: Mouse over a string array and you get this cool, scrollable, look into the data contained within.  There are also a bunch of new options for setting breakpoints and printing debug statements that are a joy to work with.  The code just seems to come alive. 




Back to 2003: 2005 can’t come soon enough.  After my three days of Whidbey enjoyment I forced myself to port my changes back to my VS 2003 project.  The IDE felt drab and un-inviting by comparison to Whidbey, but I trudged on.  I also missed the refactoring, improved debugging, and even the small features like “Open containing Folder” on the file tab channel.  If you are like me you’ll right click the VS 2003 file tabs a good 3-4 times while saying “doh” before installing this. 




For some reason, after having done a few successful builds and tests of my setup project VS 2003 feels compelled to launch some sort of VS 2005 installer on every build.  For a while I was able to cancel out of this and let the build continue, but currently I’m stuck with an “Unrecoverable Build Error” on my VS 2003 project.  To get a release I’m just going to clean a machine and start over with VS 2003 only.    


Comments (9)
  1. Kevin says:

    The issue with "Unrecoverable Build Error" is known, and actually benign (as confusing as that is). It should be fixed when you install XP SP2, which includes Windows Installer 3.0.

  2. rene says:

    I tried too beta products and I am quite disappointed.

    My project made in vs2003 could not

    work on vs2005 and after i removed

    2005 I I could not run my project on version

    2003 either, so I am stuck here and trying

    to solve the problem.

    🙂

  3. josh says:

    You should run repair on th VS 2003 install.

  4. tycho404 says:

    For me the following rule worked: Output each merge-module in a separate folder!

    In my installer project I referenced the output of 2 merge-modules. The "vdproj" project files of both merge-modules lay in the same directory e.g "mergemodules". The outputpath for was "mergemodules/release". So when I rebuilt the installer-project the first merge-module was build in "mergemodules/release". When the build of the second merge-module was started, the content of the release-folder was deleted and so also my first merge-module. The final "linking"-process now could not found merge-module one and brought the error "Unrecoverable Build Error".

    So remember to provide a separate folder for each merge-module you want to reference in your installer-project.

  5. My app building yielded the v0.8 version of the VSCmdShell Window add-in.  If you haven’t been…

  6. Steven Barnes says:

    The Unreoverable Error can also be resolved by fixing the OLE32.dll regitration.

    Check this knowledgebase article: http://support.microsoft.com/default.aspx?scid=kb;en-us;835457

  7. I was in Perth a few weeks back and whilst there I had the opportunity to watch a presentation by Charles

Comments are closed.

Skip to main content