12

I googled on this and realized there are probably several causes to this so I will describe my scenario.

This happens when my application tries to load a .dll file built in another version of Visual Studio (2010), if I build the same project on Visual Studio 2008 the DLL file loads just fine...

I don't know if it matters, but Visual Studio 2010 DLL file version is built on Windows 7 x32, and Windows Vista 64-bit is on the other side with Visual Studio 2008.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Marko29
  • 1,005
  • 4
  • 14
  • 25
  • 5
    Recompile your app in "Release" mode (rather than "Debug" mode), then download and install the Visual C++ 2010 Redistributable package for the appropriate processor architecture on the target machine: [x86](http://www.microsoft.com/downloads/en/details.aspx?FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84&displaylang=en), [x64](http://www.microsoft.com/downloads/en/details.aspx?FamilyID=bd512d9e-43c8-4655-81bf-9350143d5867). The target machine has to have the same version of the runtime installed as you built against. In this case, that's v10.0 (from VS 2010). – Cody Gray - on strike Jan 12 '11 at 12:37
  • 1
    just consult following two links: [http://www.buggymind.com/305](http://www.buggymind.com/305) [http://msdn.microsoft.com/ko-kr/library/abx4dbyh.aspx](http://msdn.microsoft.com/ko-kr/library/abx4dbyh.aspx) I hope it will help. –  Feb 17 '11 at 02:41

3 Answers3

12

If you link dynamically to the MSVC runtime then you need to install that runtime on every machine that will run your app.

Note that in this case you appear to be linking to the debug version of the runtime, it is not normal to distribute apps linked against the debug version of the runtime.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • I changed code generation option from multithread dll debug to ' multithread dll – Marko29 Jan 12 '11 at 12:21
  • compile and it didnt solve problem, i really dont know where should i look – Marko29 Jan 12 '11 at 12:22
  • Is it still reporting 100D or just 100 now? If it's 100D, you didn't get the option right or recompile it all; if it's 100 then you should get the MSVC runtime installer from your VS DVD (or you can probably download it) and run that on the target system. – Rup Jan 12 '11 at 12:26
  • 2
    @Marko29 as @Rup says, and as I said in my answer, you need to install the MSVC version 10 runtime on the target machine. You can download this from the web (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84&displaylang=en), or get it from your VS DVD. – David Heffernan Jan 12 '11 at 12:32
  • 1
    Or you could just copy them from your dev machine, c:\windows\system32. The side-by-side cache song and dance is over and done with. – Hans Passant Jan 12 '11 at 13:20
7

If you do not want to distribute the runtime, then you can switch your Runtime Library options in Visual Studio (Properties -> C/C++ -> Code Generation -> Runtime Library) from /MD to /MT or from /MDd to /MTd.

As others have said, if you are distributing this application you should be linking dynamically or statically to the Release version of the Runtime library, not the Debug version.

oob
  • 1,948
  • 3
  • 26
  • 48
2

Just an small related advice: DON'T ADD any *248d.lib files while building and running in the RELEASE version.

I was following advice from different blogs, and I accidentally added both *248d.lib as well as the 248.lib files. Basically in LinkerInputAdd Dependencies, ensure that you don't have *248d.lib files in it (here 248 is version 2.4.8).

I spent hours wondering why things weren't working in the release mode until it struck me that there are two copies of .lib files, one *248 and other *248d. If you include any of the d files in release mode, you will get the DLL issue.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
user3046045
  • 63
  • 1
  • 7