我们有一个相当大的解决方案（总共40个项目），最近我将其升级到了Visual Studio 2010。在升级时，我认为清理项目依赖关系可能是个好主意。但这正是我做不对的事情。
主要.exe（C#）依赖于一个包装非托管C++库项目的C++/CLI项目，该项目本身依赖于几个第三方库。因此，依赖树将如下所示：
- App (C# .exe) - LibWrapper (C++/CLI .dll) - CoreLib (C++.lib) - libjpeg (C.lib) - libpng (C.lib) - ...更多库 为了使一切井井有条，我希望LibWrapper仅依赖于CoreLib，而CoreLib引用其所有依赖项。我相应地设置了项目依赖关系，并且从头开始重新构建解决方案时一切都运行得很好。到目前为止，一切都很好。
然而，当我更改LibWrapper中的内容，然后尝试构建解决方案（仅重新编译和链接LibWrapper）时，链接器不会获取嵌套依赖项（libjpeg等），因此会抛出大量链接器错误。从技术上讲，这是正确的，因为链接器无法找到符号，因为它根本不查看嵌套库。但是为什么重新构建一切时会按预期工作呢？
可能是由于库依赖设置中的某些问题，但我无法弄清楚具体原因。我可以将CoreLib的依赖项添加到LibWrapper中，但我认为那有点丑陋。
对于CoreLib依赖的库，我将“引用程序集输出”和“链接库依赖项”都设置为false。对于LibWrapper中的CoreLib依赖关系，我将两者都设置为true。
更新：我找到了一个相当丑陋的解决方法，虽然不太好维护，但至少可以工作。因此，对于每个具有依赖关系的lib项目，我添加了一个列出这些依赖项的头文件。因此，例如对于CoreLib，该文件如下：
在依赖项目中，我从stdafx.h（或另一个中央位置）包含此头文件：
主要.exe（C#）依赖于一个包装非托管C++库项目的C++/CLI项目，该项目本身依赖于几个第三方库。因此，依赖树将如下所示：
- App (C# .exe) - LibWrapper (C++/CLI .dll) - CoreLib (C++.lib) - libjpeg (C.lib) - libpng (C.lib) - ...更多库 为了使一切井井有条，我希望LibWrapper仅依赖于CoreLib，而CoreLib引用其所有依赖项。我相应地设置了项目依赖关系，并且从头开始重新构建解决方案时一切都运行得很好。到目前为止，一切都很好。
然而，当我更改LibWrapper中的内容，然后尝试构建解决方案（仅重新编译和链接LibWrapper）时，链接器不会获取嵌套依赖项（libjpeg等），因此会抛出大量链接器错误。从技术上讲，这是正确的，因为链接器无法找到符号，因为它根本不查看嵌套库。但是为什么重新构建一切时会按预期工作呢？
可能是由于库依赖设置中的某些问题，但我无法弄清楚具体原因。我可以将CoreLib的依赖项添加到LibWrapper中，但我认为那有点丑陋。
对于CoreLib依赖的库，我将“引用程序集输出”和“链接库依赖项”都设置为false。对于LibWrapper中的CoreLib依赖关系，我将两者都设置为true。
更新：我找到了一个相当丑陋的解决方法，虽然不太好维护，但至少可以工作。因此，对于每个具有依赖关系的lib项目，我添加了一个列出这些依赖项的头文件。因此，例如对于CoreLib，该文件如下：
// NestedDependencies.h
#pragma once
// add nested dependencies
#pragma comment(lib, "libjpeg")
#pragma comment(lib, "libpng")
// more libs..
在依赖项目中，我从stdafx.h（或另一个中央位置）包含此头文件：
// stdafx.h
#pragma once
#using <mscorlib.dll>
#include <vcclr.h>
#include <windows.h>
#include <atlbase.h>
// whatever else
// add nested dependencies
#include "CoreLib/NestedDependencies.h"
虽然这样做可以工作，但我们团队中的每个人在添加库依赖项时都必须记得向 NestedDependencies.h 添加一行。这不太好，但还能用。
然而，我仍然希望有更好的解决方案。有人知道吗？