Always ask the developer before applying a security fix or service pack to Visual Studio that need changed the C++ runtime DLLs ATL/MFC/CRT by Martin Richter

Some security fixes and all service packs to Visual Studio changed the code base and the libraries. New runtime DLLs for MFC and CRT were introduced.
The problem is that the developer doesn't recognize this, but it will affect the complete build of all his components. Otherwise his software might not work as expected.
And this might be against his will! The impact on the complete distribution of his software is large.

The change of the import libraries isn't detected by the build system a full rebuild is not triggered for all components (static libs etc.). As a result, program files with multiple manifest entries for the CRT/MFC are created for VS-2005 and VS-2008.

As a further impact: There are third party libraries from other companies. Maybe they are not available soon for the CRT/MFC of this specific security fix. As a result they also cause multiple manifest entries to be created.
(This is also caused by the fact that the usage of _MFC_NOFORCE_MANIFEST, _ATL_NOFORCE_MANIFEST and _CRT_NOFORCE_MANIFEST was never documented. Third party libs should always be created with this defines set VS-2005, VS-2008)
Also if the developer does not roll out the new VCRedist component the newly created software may not run, because the runtimes with this new version are not found.

The impacts of such a security fix in VS-2010 are less critical because there a no longer manifests for it (Hallelujah!). But there is still no guaranty that that software build with the new code from the security fix, will run with the old runtimes. Again: At least for VS-2005/2008 this doesn’t work), and it is still true that running a program build with a higher SP than the installed runtime version might not work, or cause problems.
Another reason:
- The developer builds and ships his software with A.EXE and B.DLL linking statically or dynamic to the CRT/MFC/ATL.
- Now a security fix is installed (usually the developer isn’t informed about that!!!)
- Now he builds a new revision of B.DLL as a fix and just wants to roll out this single file.
- There is no guaranty that this will work. And for dynamic linking to VS-2005 and VS-2008 this may fail and causes extreme problems, because the target machine of the user isn’t prepared for this.

So the developer needs a method to “freeze” his development tools so that he can control how his software is build!
But even here installation of a new security fix doesn't trigger a full build for all components (the import libs are not checked in the build system, and they are published with an older date of some build-target that a developer has on his machine).
If installed they have to force a new build so that the security fix will be linked into the targets in case of static linkage to CRT and MFC.
Otherwise this is useless at all.
I.E. I have EXE files that didn't change since month, but are part of my setup. Some linked statically to CRT/MFC. Result: They didn't contain the fix even installed on my machine.

The impact of such a security fix to a complete build environment is so large that this should never happen without the knowledge and will of the developer.

And I don't want to think about a developer team, which might use different patched Versions of VS.
So from my point of view it is an error and a large problem for developer that security fixes are installed without asking him!

Resolution:
I miss documentation about the impact of such security fixes and how a developer has to care about this.
At least such a security fix should display a warning message box.
Or this fixes should only be installed on demand of the developer.
The developer needs a method to freeze is development tools to s specific version of the CRT/MFC/ATL.