I created a solution with several C++ and Managed C++ projects, each with Win32 and x64 builds.

When I click on the solution, and go to Project Dependencies, I can specify that some projects depend on others. I then go to project properties, linker, command line. The outputs of the depended projects were added to the linker command line. This is new, I 've never seen this behavior before. So by saying that Managed C++ dll project A depends on C++ lib project B, ..\b\debug\b.lib is added to the linker command line for project A. I would prefer to be in control of this stuff explicitly.

But the problem is it doesn't take into account the platform, so it adds the libraries from debug instead of from x64\debug. When I compile, I get the error about a target platform mismatch between the lib (x86) and the managed c++ dll (x64) that depends on the lib.

I'm using Visual Studio 2005 SP1, all projects are C++ and Managed C++.

Re: Visual C++ General Project Dependencies adds DLLs to linker command (x64 problem)

Bruno van Dooren

If you specify dependencies, the lib files get added to the depending project by default. Afaik you don't have control over this.

It is strange that it doesn't take the platform into account. Does this also happen when you do a clean and then a rebuild

Re: Visual C++ General Project Dependencies adds DLLs to linker command (x64 problem)


I did a full clean, closed Visual Studio, reopened it, and tried again. Same problem - it is still trying to link x86 libs with my x64 dll.

Thanks for the reply. Automatically adding .lib dependencies to the linker command based on the project dependencies is a new feature, did Microsoft add it in SP1 This seems to have broken x64 support. I'm building the projects individually now to get around this.

Re: Visual C++ General Project Dependencies adds DLLs to linker command (x64 problem)


AFAIK the automatic adding of dependent .lib files is pretty standard. My solution does it and I am using VS2005 SP1, WIN32, native and managed projects.

Having looked at my project settings, it looks like I override the auto include anyway in some cases. If you add a .lib file into the additional dependencies that has the same name it will use that instead of the automatically added one.

Hopefully that will work for you.

However, I do have a suggestion. If you can set the solution up so that you *can* use the auto added .lib files then it will probably make your solution more adaptable if you change things in the future.

Check out the output directories for the projects. If the higher level project has an output dir of debug\x64\ and the dependent projects have an output dir of debug\ then this might be where your problem is. Make sure that all projects use the same output dir (for the same config) and it may fix your problem automatically.

BTW the output dir I am talking about is the one in "Configuration properties -> General". Just to avoid confusion :-)


Re: Visual C++ General Project Dependencies adds DLLs to linker command (x64 problem)


OK I specified the libs on the "Additional Dependencies" and rebuilt. That works. The linker command line includes the ones I added explicitly first, and the automatically added ones second. The explicitly added libs take precedence, and it ignores the automatically added, incorrect platform libs.

I had originally handled lib dependencies using #pragma comment(lib, "libproject.lib") in a header file. The automatically added libs take precedence over this, resulting in an incorrect platform linker error.

My projects are all consistent in output directories, they all use: debug, release, x64\debug, x64\release. The x64 linker command line incorrectly points to ..\libproject\debug\libproject.lib, not ..\libproject\x64\debug\libproject.lib. When I added liproject.lib to "Additional Dependencies" and had an "Additional Library Directories" set to ..\libproject\x64\debug, then it works. Probably would also work if I only specified ..\libproject\x64\debug\libproject.lib to "Additional Dependencies".

This seems like a bug in Visual Studio, but at least there's a workaround.