views:

1106

answers:

4

I'm coming from a Linux background, but I'd like to provide a version of my software on Windows. For users to run my program, they will need the Visual C++ redistributable. I would like to provide it for them as part of the package.

My worry is that there, in the future, will be an SP2 of the Visual Studio 2008 Redistributable. If I provide them SP1, or ask them to install it themselves, will it clobber later versions of the dll's that may be required by future tools?

Is there any instruction to give users to make sure they do not do this?

I'd certainly not want to screw up someone's machine or other applications by giving them incorrect instructions.

Aside from the redistributable exe, I was going to provide my tool as a zip file which they can extract into any directory they please, so I was not planning on providing an installer.

+2  A: 

The VC++ redistributables are meant to be installed side-by-side and can coexist peacefully.

Here's a page from the MSDN docs about the VC++ redistributables. That whole Deployment section of MSDN should be instructive.

Nick Meyer
+6  A: 

With VS 2008 the runtimes are manifested and will install side-by-side. So if your application is linked to SP1's runtime, it will run only with the SP1 runtime (unless a manifest explicitly indicates that the Sp1 version should be overridden).

So you're protected from that type of DLL hell, in exchange for another (the user must have the SP1 redistributable installed).

Michael Burr
Your last comment in parentheses is misleading. The SP1 redist is installed and uninstalled with the app. It's not like the user has to install it seperately.
Drew Hoskins
The point is that it will still get installed even if user has SP2 already.
Pavel Minaev
@Drew - You're right - it's not a problem with applications that have a proper installer.
Michael Burr
+5  A: 

Why don't you statically link and avoid this problem altogether?

Rob
I didn't know this was possible. Would my application be future proofed? I'm worried that changes to the operating system in the future might cause the statically-linked run times to be incompatible.
Juan
If you statically link then the library code you use becomes part of your EXE, so as long as your future O/S can actually run an EXE, you'll be fine. I have apps out there written 15+ years ago that are still churning away.
Rob
Ok, this is different from linux. For example, statically linking the pthread library on linux may make your application incompatible in the future. This is from the tight interaction required by the pthread library and the os.
Juan
+1 - I can't believe I didn't think to mention this...
Michael Burr
Compile with /MT to do this. There are various reasons why this might not be possible for you, but usually you'll be okay.
Drew Hoskins
I think it's not ok when you depend on a library that was built with dynamic linkage. When you distribute your app, that lib will still need the dependencies you were trying to get rid of in the first place.
Andrei Vajna II
+2  A: 

As people said, they're installed side-by-side. If you use Visual Studio's installer project type, there's an option for including the CRT redistributable, and it will set it up properly for you to be installed and uninstalled with your application.

In particular, they're installed to the \Windows\WinSxS directory.

To get an intuition for how side-by-side works, do

cd %systemroot%\winsxs
dir /S msvc*.dll

And you will see all the versions people have put on your machine.

Drew Hoskins