Are there any side-effects of using macro _BIND_TO_CURRENT_VCLIBS_VERSION?

We are porting a VC++ project from Visual Studio 2003 to Visual Studio 2008 SP1(9.0.30729.4148). The dependent external libraries are also compiled with Visual Studio 2008 SP1.

MainApp - Main application Compiled with VS SP1 9.0.30729.4148
ExtStaticLib1 - External static library compiled with VS  SP1 9.0.30729.4148
ExtDynamicDll1 - External DLL compiled with VS  SP1 9.0.30729.4148

There are two deployment scenarios for the Main application:

• Machine with User Admin rights: We recommended to put a pre-rquisite to install Visual Studio redistributable package before using the application MainApp. This works well as user has the admin rights and installing redistributable package has no issues. Application links to the VC 开发者_如何学Credist DLLs in WinSxS folders automatically.
• Machine with non-admin user: This scenario is problematic. The user is not having the admin rights. Hence, it is not possible to install VS2008SP1 redistrtibutable package.

We are doing following to solve this:

• Compile MainApp targets with macro _BIND_TO_CURRENT_OPENMP_VERSION ( for all the projects in MainApp).

• Distribute the VS2008SP1 redistributable DLLs as private assemblies and copy them in application install directory.

Questions:

1. Is there any side-effect of using the flag _BIND_TO_CURRENT_VCLIBS_VERSION (Specially when both VC redistributable package and private VC redist assemblies exists together)?
2. We do not have much control on the external libraries ExtStaticLib1, ExtDynamicDll1 and hence, they will not be compiled with macro _BIND_TO_CURRENT_OPENMP_VERSION. But they are already compiled with VSSp1. Will there be any issue with this setup?
3. Will there be any issue if there is a newer version of VS redistributable available (newer than 9.0.30729.4248).

Thanks.

I would avoid using any of the BIND macros. You'll get into troubles sooner than later.

Even if you distribute the VC runtime dlls as private assemblies, you can't be sure that the user doesn't have them installed already with some other app.

One problem that arises is that you can end up with a manifest that references multiple c-runtime versions. Here's an open issue about this (FYI: I had that very same issue!).

So if there's no reason that would force you to only use a very specific version of the c-runtime and not the latest compatible one, then don't use those define macros!

Found this blog resource which has answer to your question. Refer section which says "Updates, patches and service packs" http://helgeklein.com/blog/2010/03/deploying-visual-c-runtime-files-as-private-assemblies/