SideBySide error on another computer with MSVC ++ 2005 installed
I am having some weird problems building and running a project on another computer. This is a side error. Usually the reason is that the C ++ distribution is not installed on the computer, etc. However, in this case, the project is compiled on this computer. MSVC ++ 2005, the runtime should be there (I set the runtime for good measure anyway). Why is the linker referring to a runtime library that is not available on the computer?
I am dynamically linking to a runtime library.
Any ideas on how to debug this issue?
Thank.
EDIT
I didn't want to start a new recording because it is related. Due to this DLL version issue, is this a good reason for static runtime reference? Will I be able to avoid all these problems? I don't see any benefit to dynamic linkage with runtime. I was under the impression that when working with DLLs, you get the benefits of updates / bug fixes with new DLLs. However, because of SxS and exhibits that it provides loading of a specific version (old version) of a DLL? So what's the point of dynamic runtime? Maybe a few kilobytes of space are saved because you are not implementing reusable functions in all dependent libraries. But compare that to the cost of your application, which won't run because some old version of the runtime is being removed from the machine, isn't it worth it?
Thanks again. Still tracking down the original issues and may have to recompile every library I use.
source to share
sxstrace
will tell you what's going on regarding SxS. It will show you which DLLs you are looking for and how they map to the actual versions.
Now the runtime is loaded from the manifest file that is included in your project. Looking at the one you mention, it is similar to the one on Visual2005 without the service pack. SP1 changed crt to 8.0.50727.762
Some information about sxstrace on Vista and XP
Okay, since you added a question to your question, let me add an answer to my answer: SxS does not necessarily download the version you specified in the manifest. SxS keeps track of security fixes made for specific versions, for example. and will change which version it downloads even when you ask for a specific version.
However, if your program uses DLLs and you want to share C objects (such as malloc'ed memory), then your only option is the CRT DLL. It really depends on your limitations.
source to share
Not the answer to the problem, but the answer to this question:
Why is the linker referring to a runtime library that is not available on the computer?
The linker does not need an actual runtime library for communication. It's just (usually) a .lib file at link time. The .lib file tells the linker that the runtime library will provide (as in exported symbols) when the OS finds the DLL at runtime.
Dependency Walker can be useful in such cases to help debug the problem.
EDIT: Move on to a new question. Static linking eliminates these problems, but it introduces some new problems as well. You can share dynamically allocated objects between dlls - however, depending on which DLL allocated the object, there must be one that frees it. Any object methods that allocate / reallocate / deactivate element data / objects in a similar manner should be managed to avoid heap corruption. Inappropriate recount / share links would be helpful. Alternatively, allocated memory allocators can be useful.
source to share
Here's a possibly related forum . Not sure if this is the problem, but it seems worth checking out.
The recap is that MS has updated ATL, CRT, MFC and a few other libraries on VS 2005 dev machines via automatic updates.
On computers without VS2005, they only updated ATL through automatic updates causing SxS errors.
You can either uninstall the update on the dev machine, or update the runtime manually on the machine you are trying to start. Details of post .
source to share