Comments on: Binding to the most recent Visual Studio Libraries http://www.nuonsoft.com/blog/2008/10/29/binding-to-the-most-recent-visual-studio-libraries/ Sharing my software development progress + other interesting things. Sat, 13 Mar 2010 17:12:23 +0000 http://wordpress.org/?v=2.7.1 hourly 1 By: klaus triendl http://www.nuonsoft.com/blog/2008/10/29/binding-to-the-most-recent-visual-studio-libraries/comment-page-1/#comment-15154 klaus triendl Fri, 25 Dec 2009 23:41:46 +0000 http://www.nuonsoft.com/blog/?p=81#comment-15154 I don't see any DLL hell here... the important thing to keep in mind is to distribute the merge modules for the runtime as well as the merge modules for the policy files! Example scenario: - Setting the macro _BIND_TO_CURRENT_VCLIBS=1 (as C/C++ preprocessor macro as well as for the midl compiler) for our projects results in a manifest binding to the runtime with version 9.0.30729.1 - Because we're using a static 3rd-party library that we cannot influence, and whose manifest binds to the RTM version of the runtime (9.0.21022.8), the final manifest for my applications contains dependencies on two versions of the runtime - Our install packages deploy the newest runtime via the most recent merge modules available, which currently is version 9.0.30729.4148 Everything goes like clockwork as long as the policy files are present. Tested on fresh windows server 2003 and windows xp professional installations without WinSxS runtime assemblies being present on the system. I don’t see any DLL hell here… the important thing to keep in mind is to distribute the merge modules for the runtime as well as the merge modules for the policy files!

Example scenario:
- Setting the macro _BIND_TO_CURRENT_VCLIBS=1 (as C/C++ preprocessor macro as well as for the midl compiler) for our projects results in a manifest binding to the runtime with version 9.0.30729.1
- Because we’re using a static 3rd-party library that we cannot influence, and whose manifest binds to the RTM version of the runtime (9.0.21022.8), the final manifest for my applications contains dependencies on two versions of the runtime
- Our install packages deploy the newest runtime via the most recent merge modules available, which currently is version 9.0.30729.4148

Everything goes like clockwork as long as the policy files are present.
Tested on fresh windows server 2003 and windows xp professional installations without WinSxS runtime assemblies being present on the system.

]]> By: Marc Gregoire http://www.nuonsoft.com/blog/2008/10/29/binding-to-the-most-recent-visual-studio-libraries/comment-page-1/#comment-5459 Marc Gregoire Thu, 02 Apr 2009 07:06:12 +0000 http://www.nuonsoft.com/blog/?p=81#comment-5459 I agree. The good news is that all this will be changed in Visual C++ 2010. Basically the new deployment model goes back to the VC6 days, solving all those Windows SxS issues. See http://blogs.msdn.com/vcblog/archive/2008/10/28/visual-studio-2010-ctp-released.aspx I agree.
The good news is that all this will be changed in Visual C++ 2010. Basically the new deployment model goes back to the VC6 days, solving all those Windows SxS issues.
See http://blogs.msdn.com/vcblog/archive/2008/10/28/visual-studio-2010-ctp-released.aspx

]]> By: John http://www.nuonsoft.com/blog/2008/10/29/binding-to-the-most-recent-visual-studio-libraries/comment-page-1/#comment-5443 John Wed, 01 Apr 2009 21:03:34 +0000 http://www.nuonsoft.com/blog/?p=81#comment-5443 Well... went from DLL hell straight into something far far worse. Well… went from DLL hell straight into something far far worse.

]]>