2
votes

I hope you can help me with this.

I want to build a dll (statically linking other, non-third-party libraries) using version 4053 of the CRT (/MD) instead of the latest (5592) in Visual Studion 2005 SP1.

I'm wondering if using the following method is enough to accomplish this. By using this method in all dependent projects of the solution, to my understanding, the dll's embedded manifest is altered to state the CRT (and MFC, ATL) version requested. Is this assumption correct?

Is simply making sure the dll's embedded manifest states the wanted version enough? Shouldn't I also use the correct import library (msvcrt.lib) belonging to the older (4053) CRT dll (msvcr80.dll) when building my dll (with ignore specific library)? How is this import library (msvcrt.lib) changed with minor version changes like this?

Thanks in advance!

Marc Maussen

1

1 Answers

1
votes

The CRT version number is declared in vc/include/crtassem.h. For MFC it is vc/atlmfc/include/mfcassem.h. For ATL it is vc/atlmfc/include/atlassem.h. If you got the security update installed on your dev machine then these files will be updated. Using #define _CRT_ASSEMBLY_VERSION x.y.z.w (etcetera) before #including any CRT header will override that version number. So does uninstalling the security update.

This is otherwise unwise, the target machine is still going to use the .5592 revision of the DLL if it has the security update installed. It deploys a 'publisher policy' that redirects the version number, ensuring that old programs automatically get patched. Testing the version that runs on your customer's machine is of course always best. And shipping an installer with a known security problem is very rarely appreciated by customers.