2

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

skaffman
  • 398,947
  • 96
  • 818
  • 769

1 Answers1

1

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.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Thank you for your quick response! So if I wanted to do this, despite it being unwise, I do not also need to build using the import lib (msvcrt.lib) belonging to .4053 version next to defining _CRT_ASSEMBLY_VERSION? Building on my dev machine with the lib belonging to .5592 will work? No interface/definition change during minor update/security patch? Thanks again! – Marc Maussen Apr 26 '11 at 13:19
  • The import library didn't change, using the .5592 msvcrt.lib is fine. – Hans Passant Apr 26 '11 at 17:59
  • Good to know! Does the import library ever change (without changing VS version)? With a major increase of the CRT version perhaps (do those even occur)? If the import library would change, how does the 'publisher policy' handle this? Redirecting to the latest dll while having been build with a different (in this scenario) import lib? Thank you for your time Hans! – Marc Maussen Apr 27 '11 at 06:17
  • No, yes, it doesn't. Please close your question by marking it answered. – Hans Passant Apr 27 '11 at 09:05