Visual Studio 2005 SP1 included new versions of some C++ libraries. Your application's manifest specifies what versions of the DLLs it wants -- so if you build with SP1, the application is going to look for SP1 versions at runtime. That has consequences for your deployment strategy, since non developers are unlike to have SP1 versions of those DLLs yet.
Nikola Dudar has gathered some questions and answers on this topic. I'll give you the questions, read his blog for the answers:
- It looks like with VS2005 SP1 if a new version of VC++ libraries is installed, all apps start using it. Is this new policy for VS2005 SP1?
- When my application is rebuilt with VS2005 SP1 it runs only when SP1 versions of VC++ are installed. Why does not it run when RTM versions of libraries are installed? Is this new policy for VS2005 SP1?
- This behavior of VC++ libraries in VS2005 SP1 is it only specific to SP or is it going to be same in future releases of SP and hotfixes?
- Wasn't the whole point of manifests to allow applications to specify the versions of VC++ libraries they want to load?
- My application is using a DLL that is built with VS RTM. The application links against import library of that DLL and call exports of that DLL at runtime. Is this going to work with VS2005 SP1 and other SPs?
- My final product is a set of DLLs. If I release a version of my DLLs built with VS2005 SP1, can my users who use VS2005 RTM to use these libraries?
- My application is linking to static library party is built with VS RTM. Is this going to work with VS2005 SP1 and other SPs?
- I see VS2005 SP1 has installed SP1 version of VCRedist*.EXE. Should I send it to my customers and ask them to install it?
- I am using MSMs to redistribute RTM versions of VC++ libraries. Should I sent SP1 version of VCRedist.EXE to my customers and ask them to install it?
If these questions matter to you, then you have a blog post to read, don't you?