使用 MSVC++ 的另一台计算机上出现 SideBySide 错误2005年安装
我在另一台计算机上构建和运行项目时遇到一些奇怪的问题。这是一个并排错误。通常原因是计算机上未安装 c++ 可再发行组件等。但是在这种情况下，项目是在该计算机上编译的。 MSVC++ 2005 已安装，运行时应该在那里（为了更好的测量，我再次安装了运行时）。为什么链接器引用机器上不可用的运行时库？
我动态链接到运行时库。
关于如何调试这个问题有什么想法吗？
谢谢。
编辑
我不想开始另一篇文章，因为它是相关的。由于 DLL 版本混乱，这是静态链接到运行时的好理由吗？我能避免所有这些问题吗？我不再看到动态链接到运行时的任何优势。我的印象是，通过 DLL 运行时，您可以获得新 DLL 的更新/错误修复的好处。然而，由于 SxS 和清单，它确保它加载 DLL 的特定版本（旧版本）？那么动态运行时到底有什么意义呢？也许节省了几 kb 的空间，因为您没有将重用函数嵌入所有依赖库中。但是，将此与您的应用程序无法运行的成本进行比较，因为某些古老的运行时版本已从计算机中删除，这不值得吗？
再次感谢。仍在追踪原始问题，并且可能必须重新编译我正在使用的每个库。
I'm having some strange issues building and running a project on another computer. It's a side-by-side error. Usually the cause is that c++ redistributable is not installed on the machine etc. However in this case the project is compiled on that machine. MSVC++ 2005 is installed, the runtimes should be there (I installed the runtime again for good measure anyway). Why is the linker referencing a runtime library that isn't available on the machine?
I'm dynamically linking to runtime library.
Any ideas on how to debug this issue?
Thanks.
EDIT
I didn't want to start another post because it's related. Because of this DLL version mess, is this a good reason to statically link to runtime? Will I avoid all these problems? I don't see any advantages to dynamically link to runtime any more. I was under the impression that with DLL runtime you get the benefit of updates/bug fixes with new DLLs. However because of the SxS and manifests it ensures that it loads the specific version (old version) of the DLL anyway? So what's the point of dynamic runtime at all? Maybe a few kb of space saved because you're not embedding the re-used functions in all the dependent libraries. But compare this to the cost of your app won't run because some ancient runtime version is removed from the machine, isn't it worth it?
Thanks again. Still tracing the original problems and will probably have to recompile every single library I'm using.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
sxstrace将告诉您 SxS 到底发生了什么。它将显示搜索了哪些 dll 以及它们如何映射到实际版本。现在，加载的运行时来自项目中包含的清单文件。看你说的那个，好像是Visual2005的，没有service pack。 SP1 将 crt 更改为 8.0.50727.762
vista 上 sxstrace 的一些详细信息和 XP
好吧，既然你在问题中添加了一个问题，那么让我在我的答案中添加一个答案：
SxS 不一定会加载您在清单中指定的版本。 SxS 系统会跟踪对特定版本进行的安全修复，例如，即使您要求特定版本，也会更改其加载的版本。
也就是说，如果您的程序使用 DLL，并且您希望在它们之间共享 C 对象（例如 malloc 内存），那么您唯一的选择就是 CRT DLL。这实际上取决于你的限制是什么。
sxstracewill tell you exactly what is going on with respect to SxS. It will show what dlls are searched and how they are mapped to actual versions.Now, which runtime is loaded is coming from the manifest file that gets included in your project. Looking at the one you mention, it looks like the one from Visual2005, with no service pack. SP1 changed the crt to 8.0.50727.762
Some details on sxstrace on vista and XP
Well, since you added a question to your question, let me add an answer to my answer:
SxS will not necessarily load the version you specify inside your manifest. The SxS system keeps track of security fixes made to specific versions, e.g. and will change which version it loads even when you ask for a specific version.
That said, if your program uses DLLs, and you want to share C objects (e.g. malloc'ed memory) between them, then your only option is the CRT DLL. It really depends what your constraints are.
当您编译在另一台计算机上编译的第三方库或目标文件并在出现问题的计算机上复制时，可能会发生这种情况。
尝试在您的计算机上找到此类二进制文件，并在该计算机上重新编译它们。
It may happen when you compile along a third party library, or object files, that you compiled on another machine and the copied on the machine where the issue occurs.
Try to find such binary files on your machine, and recompile them on that machine.
不是问题的答案，而是这个问题的答案：
链接器不需要实际的运行时库来链接。它只需要（通常）链接时的 .lib 文件。 .lib 文件告诉链接器当操作系统在运行时找到 dll 时，运行时库将提供什么（如导出的符号）。
Dependency Walker 在此类情况下可以帮助调试问题。
编辑：新问题的后续行动。静态链接确实解决了这些问题，但它也引入了一些新问题。您可以在 dll 之间共享动态分配的对象 - 但是，分配该对象的 dll 必须是释放该对象的 dll。对象上任何类似地分配/重新分配/取消分配成员数据/对象的方法都必须受到管理，以避免堆损坏。非内联引用计数/共享指针会很有帮助。或者，共享内存分配器可能会有所帮助也。
Not an answer to the problem, but an answer to this question:
The linker doesn't need the actual runtime library to link. It just needs (typically), the .lib file at link time. The .lib file tells the linker what the runtime library will provide (as in exported symbols) when the OS locates the dll at runtime.
Dependency Walker can be helpful in cases like this to help debug the problem.
EDIT: followup to the new question. Static linking does resolve these issues, however it also introduces some new issues. You can share dynamically allocated objects between dlls - however, whichever dll allocated the object must be the one to deallocate it. Any methods on the object that allocate/reallocate/deallocate member data/objects similarly must be governed in order to avoid heap corruption. Non-inline refcounting/shared pointers will be helpful. Alternatively, shared mem allocators can be helpful too.
这是可能相关的论坛帖子。不确定这是否是问题所在，但似乎值得检查。
总结是，MS 通过自动更新更新了 VS 2005 开发人员计算机上的 ATL、CRT、MFC 和其他一些库。
在没有安装VS2005的机器上，他们只通过自动更新更新ATL，导致SxS错误。
您可以在开发计算机上卸载更新，也可以在您尝试运行的计算机上手动升级运行时。有关帖子。
Here's a possibly related forum post. Not sure if this is the problem, but it seems worth checking.
The summary is that MS updated the ATL, CRT, MFC, and a few other libraries on VS 2005 developer machines via an automatic update.
On machines without VS2005 installed, they only updated the ATL via an automatic update, causing SxS errors.
You can either uninstall the update on the dev machine, or upgrade the runtimes manually on the machine you're trying to run on. Details on the post.