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. Tue, 31 Jan 2012 17:12:28 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Kristian Nilssen http://www.nuonsoft.com/blog/2008/10/29/binding-to-the-most-recent-visual-studio-libraries/comment-page-1/#comment-26934 Kristian Nilssen Wed, 26 Jan 2011 09:06:15 +0000 http://www.nuonsoft.com/blog/?p=81#comment-26934 So when I deploy my exe and the manifest of that exe says 9.0.21022.8 and the end user has 9.0.30729.4148 installed, does the end user still have to install 9.0.21022.8? Is there any way of telling vs2008 to use a specific redist? Our solution has about 60 projects in it and I don't want to modify 60 project settings. Thanks. So when I deploy my exe and the manifest of that exe says 9.0.21022.8 and the end user has 9.0.30729.4148 installed, does the end user still have to install 9.0.21022.8?

Is there any way of telling vs2008 to use a specific redist? Our solution has about 60 projects in it and I don’t want to modify 60 project settings. Thanks.

]]> By: Dimitrios Staikos http://www.nuonsoft.com/blog/2008/10/29/binding-to-the-most-recent-visual-studio-libraries/comment-page-1/#comment-19929 Dimitrios Staikos Wed, 05 May 2010 07:18:27 +0000 http://www.nuonsoft.com/blog/?p=81#comment-19929 You rule!!! I noticed myself by opening the embedded manifest that it specified a different version (an earlier version), but I thought that it would work ok if you request an earlier version and find a newer one. And why all this? Because some sucker wanted to make a really trivial exported class in a DLL and made the DLL an MFC extension DLL, so I could not recompile with static MFC. Arghhh!!! My rule is this: ALWAYS STATIC LINKING. You simply reduce dramatically the problem surface area :-) Thanks! You rule!!!
I noticed myself by opening the embedded manifest that it specified a different version (an earlier version), but I thought that it would work ok if you request an earlier version and find a newer one.
And why all this? Because some sucker wanted to make a really trivial exported class in a DLL and made the DLL an MFC extension DLL, so I could not recompile with static MFC. Arghhh!!!
My rule is this: ALWAYS STATIC LINKING. You simply reduce dramatically the problem surface area :-)
Thanks!

]]> 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.

]]>