Design time Side by Side poll (installing different versions of visual studio)


I became involved in the Side by Side and compatibility work items after making the mistake of voicing the fact that I did not like these scenarios. Life can laugh at you that way well enough on it’s own, but in Microsoft a comment like that is like playing with fire. I have grudgingly come to accept runtime side by side behavior, I make no claims of understanding the path forward (how do you go from three to four runtimes?) and I am now looking for information on design time side by side.

You have probably noticed by now that there is more than one version of the framework, we tried to mask this at first by making our second framework a point release but now that 2.0 is coming out there is nowhere to hide. I am really trying to get a feel for how people are using our design time components (Visual Studio). It would be extremely helpful if you could leave some feedback with your thoughts/opinions.

1. Have you installed VS2002 and VS2003 Side by Side on the same machine?
2. Are you thinking about installing VS2003 and VS2005 (when it releases)?
3. If you are a developer that needs to use two versions of VS are you just using different boxes or Virtual PC / VMWare?
4. What are the most important install / uninstall scenarios (the ones we need to get right)?  For example, a trial scenario where someone has VS2003, installs VS2005 trial, migrates all their work and then uninstalls VS2003 and activates VS2005.

I would really appreciate any feedback, I will compile this information and present it to the side by side working group so your vote definitely counts. Thanks for your help.
Rambling out

Comments (9)
  1. Seth Porter says:

    I’ve had VS 2002 and 2003 side-by-side since 2003 was released, though I could probably get rid of 2002 now (we finally required our users to bump up to 1.1). I’ll definitely need to keep 2003 side-by-sude with 2005, to get used to the tools and test things out, while still doing my mainline work (and release builds and debugging) under 2003. We aren’t going to be able to push our users to 2.0 for at least a couple of years (there’s always someone with a 56k line and a loud voice), so side-by-side is vital for me.

    I can’t stand VS inside Virtual PC, and we talk to the graphics hardware too much anyway for it to be very useful. I can’t really justify different boxes just for different versions, and it would be a hassle anyway — lots of oddball files and utilities that I just count on having in reach.

    Personally, un_installing is only of interest if side-by-side is broken in a way that effects my older version (since I have to make release builds of some of our apps that target a given version of the framework). The newer version is generally for playing and utility programs, until we gain some confidence and the framework stabilizes.

    _Please don’t break side-by-side! I need to be able to go back and rebuild our oldest app with just a small change, with confidence that it’s the same toolchain it ever was!

    Sincerely,

    Seth

  2. my dev-box, most of my teams members, and the nightly build boxes have:

    1. Visual Studio 6.0 (for current VB6 apps that are still evolving)

    2. Visual Studio 2002 (for all current C/C++/MFC/wxWidgets projects)

    3. Visual Studio 2003 (for the slow/eventual migration away from 2002

    Side-by-Side support and arbitraty install/uninstall order really NEEEDS to be suppproted by VS.2005 when it ships.

    It is possible that our entire code base may end up skipping the 2002 -> 2003 path and just leap-frog from 2002 to 2005 when it ships, but that depends on many unknowns at this time.

    I think it is unacceeptable for any of the VS.Versions/Years to not be independantly installed and uninstalled in any RANDOM order. Installing (or uninstalling) any version of VS6,VS2002,VS2003,VS2005 in any order should NOT break any other installed app from the same family (or any app for that matter).

    New versions of VS should give me a "choice" to NOT overright existing project and solution files when they change from version to version. Give me the option to save to a new file name.. or start using a version numbering scheme as part of the project/solution file extentions: for exmpale .vcproj2002 and .vcproj2003, and .sln2002 and .sln2003

    Or better yet.. start using a "smart" versioned file format (XML??) like the MS-Office family does with .doc files so that older versions of VS projects can still parse and read the newer files and just ignore the options it doesn’t know about.

    From reading many msdn blogs (The old new thing) that talk about Microsofts painstaking efforts to maintain backward compatibilty with legacy apps accross the family of Windows OS Platoforms… it seems like a total contradiction of logic and policy for the microsoft Visual Studio family of products to be incompatible in any way on the same box.

    Something that annoys me is that when VS.2003 imports a VS.2002 project, it forcess me to overwrite the existing VS.2002 project with the VS.2003 format. I should be given the option to save the post-imported 2002->2003 project to a new file name of my choice so that i can migrate the projects over slowly using my revision contol system; instead of forcing every one to migrate at the same time!

    Don’t waste your development efforts trying to accomodate the "PreRelease Version" crowd issues.. People who want to evaluate the "PreRelease Versions" SHOULD use a different box or at least a VMWare/MSVirtualPC hosted OS to test.

    Uninstalling an older VS.year after migrating all projects to VS.year+1 should NOT break all old VS.year projects that I still have in my revision control system or on my disk for that matter.

    1. Have you installed VS2002 and VS2003 Side by Side on the same machine?

      No, uninstalled 2002 when I went with 2003 beta.

      2. Are you thinking about installing VS2003 and VS2005 (when it releases)?

      Absolutely! This is a must! Way too much stuff to do an immediate cut over and getting a new box won’t be an option (I still have two years to go on my current dev machine).

      3. If you are a developer that needs to use two versions of VS are you just using different boxes or Virtual PC / VMWare?

      I’ve been contemplating going with VMWare, but haven’t pulled the trigger on that one yet. Would rather that 2005 didn’t force the issue.

      4. What are the most important install / uninstall scenarios (the ones we need to get right)? For example, a trial scenario where someone has VS2003, installs VS2005 trial, migrates all their work and then uninstalls VS2003 and activates VS2005.

      Don’t care about the trials, definitely care about release.

  3. Paul Gibson says:
    1. Have you installed VS2002 and VS2003 Side by Side on the same machine?

      Yes

      2. Are you thinking about installing VS2003 and VS2005 (when it releases)?

      Yes, definately. We have many products at various points in the product lifecycle, not all will be able to go to VS2005 at the same time.

      3. If you are a developer that needs to use two versions of VS are you just using different boxes or Virtual PC / VMWare?

      While I am a fan of VPC, the illusion in my opinion is not yet perfect enough that I have decided to go 100% virtual. Thus I will continue to use a single development machine that is a real machine and leave the VMs for obscure one-off testing chores mostly.

      4. What are the most important install / uninstall scenarios (the ones we need to get right)? Um… How about "Side-by-side"! Meaning, VS2003 and VS2005 should no more interfere with each other than 2 completely unrelated products. Of course only release builds would absolutely have to meet this requirement.

  4. Aaron Junod says:

    I had 2002 and 2003 installed together since 2003 came out until a month ago when I redid the laptop. Never had an issue, but some of the developers I work with had odd issues when installing 2002 after 2003 was installed.

    As far as 2k5 and 2k3 side by side, this is an absolute must. I am actually already running 2k3 and B1 of 2k5 on a home sandbox, and haven’t had any issues yet, although I have not done a whole lot with whidbey yet on that box.

    I doubt I could go fully vpc. I carry a vpc with whidbey, but the performance hit is enough to make me not do it 100%. Maybe if my lappy had a couple more gigs of ram I guess, but not yet.

  5. . says:
    1. Have you installed VS2002 and VS2003 Side by Side on the same machine?

      Yes.

      2. Are you thinking about installing VS2003 and VS2005 (when it releases)?

      I am assuming that I can install it side by side (see below).

      3. If you are a developer that needs to use two versions of VS are you just using different boxes or Virtual PC / VMWare?

      No. Side by side by side installation is what we’re doing (see below). We’re starting to use Virtual PC (as we slowly roll through hardware upgrades) but I doubt we would use multiple Virtual PCs with one version of VS.Net in each Virtual PC.

      4. What are the most important install / uninstall scenarios (the ones we need to get right)? For example, a trial scenario where someone has VS2003, installs VS2005 trial, migrates all their work and then uninstalls VS2003 and activates VS2005.

      Inside of a Virtual PC image:

      1. install base OS

      2. Install VS 6

      3. Install VS.Net 2002

      4. Install VS.Net 2003

      5. Install VS.Net 2005

      6. save Virtual PC Image

      7. run image until something bad happens

      8. restore virtual PC image saved in step 6

      9. patch

      10 goto step 7

      We have about 75 person years invested in a set of VS 6 (ASP 3 / VB 6) applications. While new applications are being done in VS.Net 2002/2003, it will be a long time before we have the staffing to migrate the ASP 3 / VB 6 applications to VS.Net 200x. In the VS.Net 2005 timeframe, we will need to run the above scenario because we will have applications running using VB 6, .Net 1.0, .Net 1.1, and .Net 2.0, partially on Windows 2000 Server and partially on Windows Server 2003.

  6. Daniel Moth says:

    VS2003 and VS2005 must be fully supported side-by-side. This will certainly be true for the desktop applications but for Compact Framework applications we will need to target CF 1.0 (since CF 2.0 will not run on >WM2003 or >CE 5.0) hence will need to still use VS2003.

    My £0.02

    1. Have you installed VS2002 and VS2003 Side by Side on the same machine?

      Yup.

      2. Are you thinking about installing VS2003 and VS2005 (when it releases)?

      Yup (assuming side by side thing).

      3. If you are a developer that needs to use two versions of VS are you just using different boxes or Virtual PC / VMWare?

      VirtualPC – it seems the cleanes solution to me. Specially for testing different VS.NET betas. There is another reason why I use VPC: 3rd party components versions – I have some legacy apps that requires older versions of 3rd party components. Since VS.NET doesn’t support different component versions (not without a lot of hassle) I am forced to use VPC.

      4. What are the most important install / uninstall scenarios (the ones we need to get right)? For example, a trial scenario where someone has VS2003, installs VS2005 trial, migrates all their work and then uninstalls VS2003 and activates VS2005.

      I don’t think I’ll uninstall 2003 in near future (legacy applications), but I suppose random install/uninstall would be the best way.

  7. Bill says:

    1) Yes

    2) Yes, and have all three installed currently

    3) In development, I’ll probably need both. I definitely keep as much as I can on VM, but that also consumes a good bit of memory and a big reason for using the VM is because I had some issues getting VS 2005 installed.

    4) I’ve had a nightmare installing newer versions of the Whidbey bits until I got the last set. Every interim set told me I had to unintall previous versions even though I already did. I got some help from people at MS who pointed me to the registry keys, but I don’t think a lot of folks have the wherewithal to go through that experience.

    Also, I start to get REALLY scared every time I need to uninstall something that Works to add something new. I got burned with Whidbey pretty bad and had the same problem once when going from VS.NET to 2003. So, if it could say "You’ll need to uninstall this before we can proceed but if you click X, we’ll install the build and only after successful completion will we undo your old install", like a morphed version of XP’s reset points – it would be very very cool. Another thing – It took me forever (until the Express editions came out) to get Whidbey reinstalled. Then I got the latest MSDN bits and it was clean. So when I tried to install Yukon and it told me to Uninstall every previous version of the framework, I was very ambivalent to do so. When I did Yukon didn’t install correctly (the first build) but fortunately I could in fact reinstall the old framework and things worked — this was however a time muncher. I do enough beta stuff to have an extra machine or two, but on the prod machine it gets uncomfortable.

    However, I’ve got to give MS credit on this one, the last version of VS installed clean as a whistle and so did Yukon and if it can install with relative assurance of not causing other stuff to break and not be able to be fixed then this will cease to be a problem – I’ve got enough confidence in the newer builds not to lose too much sleep over it.

    All in all, I have to say that the inconveniences were WELL worth any hassle I had and as theings progressed – it’s a lot better. The new features make things much more pleasant 😉

Comments are closed.

Skip to main content