Installing VS6 After VS.Net 2003

  • Thread starter Thread starter Gerald Hernandez
  • Start date Start date
G

Gerald Hernandez

One of my development PC's died, and I need to have legacy VS and VS.Net
installed at the same time. On the now dead PC, I had VS6 installed prior to
installing VS.Net. This worked just fine.

On my working PC, I already have VS.Net installed, but not VS6.
My question, will installing the older VS6 with VS.Net already installed
give me problems with VS.Net. Or should I first remove the VS.Net, install
VS6, then re-install VS.Net?

Gerald
 
One of my development PC's died, and I need to have legacy VS and VS.Net
installed at the same time. On the now dead PC, I had VS6 installed prior to
installing VS.Net. This worked just fine.

On my working PC, I already have VS.Net installed, but not VS6.
My question, will installing the older VS6 with VS.Net already installed
give me problems with VS.Net. Or should I first remove the VS.Net, install
VS6, then re-install VS.Net?

Gerald
Click to expand...

For what it's worth, I have done it that way and didn't experience any
issues - that I could tell. However, I don't believe that is the
recommended way to go about it. So, as usual in these sort of
situations - YMMV.
 
Gerald Hernandez said:
One of my development PC's died, and I need to have legacy VS and VS.Net
installed at the same time. On the now dead PC, I had VS6 installed prior to
installing VS.Net. This worked just fine.

On my working PC, I already have VS.Net installed, but not VS6.
My question, will installing the older VS6 with VS.Net already installed
give me problems with VS.Net. Or should I first remove the VS.Net, install
VS6, then re-install VS.Net?
Click to expand...


As a general rule, it's always best to install an older version first and
then install the newer version. This rule doesn't really apply to VB6 and
VB.NET because VB.NET is so radically different from VB6 that they share few
(if any) files.

So, the answer to your question is that you shouldn't encounter problems
installing VB6 if VB.NET is already installed. However, it's ALWAYS a good
idea to back things up first. That's just common sense (or should be).

There is ONE thing to be careful about that I know of. If you have
installed (or will install) Visual Studio Installer for VS6, it conflicts
with the .NET VSI. To my knowledge, there's nothing you can do about that.
If you open a VSI6 (meaning VSI for Visual Studio 6) project in VSI.NET
(Visual Studio Installer for .NET), the project will be irrevocably
converted (IOW, no way to then open it in VSI6). Maybe MS has corrected this
issue. The real danger is double-clicking a .wip file (or otherwise opening
it via association). But if you had both VS6 (with VSI also installed) and
VS.NET installed on the same PC previously, you're probably aware of this
problem.

Mike
 
YES there IS a problem, although it is possible that your customers will see
it first...

I have VB6 and VB7 running on the same machine, and products compiled and
packaged by VB6 on that machine would require the customer to reboot their
machine during the installation process for a particular un-specified series
of component upgrades. The upgrade failed quietly, and on reboot and rerun
of setup, the same request was made to reboot and rerun setup. This problem
only became apparent after the release of WinXP-SP2 on a package that had
been installing perfectly to older instances of WinXP.

The experience was very embarrassing, and I have since returned to a legacy
system (an old Win98SE box) with no VB7 for compilation and packaging. The
problem could be Win XP's SP2, it could be VB7, or it could be both. I have
not had any constructive feedback yet on whether VB7 users have experienced
the same problem since the release of WinXp-SP2 - So I'll be sitting on my
VB7 license for at least another ninety days before beginning to incorporate
VB7 into my development schedule...
 
MikeD said:
prior


As a general rule, it's always best to install an older version first and
then install the newer version. This rule doesn't really apply to VB6 and
VB.NET because VB.NET is so radically different from VB6 that they share few
(if any) files.

So, the answer to your question is that you shouldn't encounter problems
installing VB6 if VB.NET is already installed. However, it's ALWAYS a good
idea to back things up first. That's just common sense (or should be).

There is ONE thing to be careful about that I know of. If you have
installed (or will install) Visual Studio Installer for VS6, it conflicts
with the .NET VSI. To my knowledge, there's nothing you can do about that.
If you open a VSI6 (meaning VSI for Visual Studio 6) project in VSI.NET
(Visual Studio Installer for .NET), the project will be irrevocably
converted (IOW, no way to then open it in VSI6). Maybe MS has corrected this
issue. The real danger is double-clicking a .wip file (or otherwise opening
it via association). But if you had both VS6 (with VSI also installed) and
VS.NET installed on the same PC previously, you're probably aware of this
problem.

Mike
Click to expand...

Just to amplify on what Mike alluded to, the biggest annoyance is perhaps
that many file associations are converted back to VS6 tools. This has less
effect on VB than on C/C++ and how annoying depends on which environment you
consider your 'primary' one.

-ralph
 
This I have run into countless times in the past. I don't think it has
anything to do with VS7. The problem I usually have is due to the service
pack on client or build machine.
The setup package has different version of control(s) than the client
machine. When you run the package, it tries to upgrade the control on the
client machine. Client reboots, file protection kicks in and replaces the
changed file with the original file. Setup package notices it needs to
upgrade. Endless loop.
The way to fix is to manually edit the setup project and/or include specific
control versions.
When you go back and build on legacy machine, it uses the older version
controls, which don't need upgrading, so they are just ignored on install.
I have not made the jump to XP-SP2 yet. But am assuming this is the same
thing I have seen numerous times with Win2K. Exact same behaviour.

Gerald
 
Back
Top