在 DLL (VS2005 SP1) 中使用 CRT (/MD) 版本 4053，而不是最新版本 (5592)
我希望你能帮我解决这个问题。
我想使用 CRT (/MD) 版本 4053 而不是 Visual Studion 2005 SP1 中的最新版本 (5592) 构建 dll（静态链接其他非第三方库）。
我想知道是否使用以下 方法足以完成此任务。根据我的理解，通过在解决方案的所有依赖项目中使用此方法，dll 的嵌入式清单将被更改以声明请求的 CRT（和 MFC、ATL）版本。这个假设正确吗？
仅仅确保 dll 的嵌入清单指明所需的版本就足够了吗？在构建我的 dll（忽略特定库）时，我是否也应该使用属于旧版（4053）CRT dll（msvcr80.dll）的正确导入库（msvcrt.lib）？这个导入库（msvcrt.lib）是如何随着像这样的小版本更改而改变的？
提前致谢！
马克·莫森
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
CRT 版本号在 vc/include/crtasem.h 中声明。对于 MFC，它是 vc/atlmfc/include/mfcassem.h。对于 ATL，它是 vc/atlmfc/include/atlassem.h。如果您的开发计算机上安装了安全更新，那么这些文件将被更新。在 #include any CRT 标头之前使用 #define _CRT_ASSEMBLY_VERSION xyzw （等等）将覆盖该版本号。卸载安全更新也是如此。
否则这是不明智的，如果目标计算机安装了安全更新，它仍然将使用 DLL 的 .5592 版本。它部署了一个“发布者策略”来重定向版本号，确保旧程序自动得到修补。测试在客户机器上运行的版本当然总是最好的。交付具有已知安全问题的安装程序很少受到客户的赞赏。
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.