我们的产品需要一个静态库（.lib）文件作为Vendor API的一部分进行链接。
我有一个为API定义的项目，它提供了许多函数和类，并生成.lib文件。
但是对于链接并由客户端使用的.lib，它还需要链接来自供应商的静态预先提供的.lib。
所以依赖树是：
我的应用程序 - > API Wrapper Lib - > Static Lib
我可以简单地告诉VS我的应用程序依赖于API Wrapper Lib - 所以我的应用程序将链接到API Wrapper Lib生成的.lib文件。但它无法链接供应商的静态lib文件。
在My App中的链接器设置下，我可以添加“其他依赖项”并将“Static.lib”命名为依赖项 - 然后添加“其他目录”并指定静态lib所在的文件夹。
这有效。
我可以交替使用：
#pragma comment(lib, "static.lib")
在我的应用程序引用的API Wrapper Lib的主标题中。这消除了在我的应用程序中需要“附加依赖项”设置。但是，除非我仍然指定“其他目录”来命名“static.lib”所在的文件夹，否则这将无法工作，即使它与API Wrapper Lib所在的文件夹位于同一文件夹中。
我的问题是：有没有更简单的方法来设计API Wrapper Lib，以便它将static.lib嵌入其自身，或自动告诉链接器“嘿，当人们链接到我的.lib时，请确保你也看”static.lib “解决任何遗漏的符号”
或类似的东西..
#pragma comment(lib, ...)很酷 - 但我还是要通过对包装文件夹的特殊引用来污染My App项目，除了告诉它“你是依赖于包装器库的链接”。
似乎冗余和凌乱 - 总是更好地设置一个东西 - 最好由包装器库设置，以便在这一端处理所有事情 - 并且客户端只需要包含并指定对一件事的依赖。
救命！
与所有“最佳”问题一样，我不能确定我的解决方案是“最好的” - 只有它是“功能性的”并且比我提出的任何其他问题更能满足我的要求。
本质上，我已经决定使用pragma注释来告诉链接器“链接到以下文件”，并且我已经包含了它的相对路径。
这意味着我正在断言这个库文件相对于需要使用它的客户端项目的位置。这可能不适合您的情况？但如果确实如此，这确实有效。
我也可以简单地拼写出这个文件的确切位置作为绝对路径。这消除了我需要标准化什么客户端项目关系将这个“注入”静态库的包装器API库，但是需要一个绝对路径，这意味着这个包装器库无法移动。
无论哪种方式都有一些限制，一些不太理想的东西。
如果我有办法从编译器获取当前项目的路径，以宏的形式，我会是金色的！我可以使用当前的绝对路径来准确地给出我需要的东西。唉，我认为无法从MS Visual Studio中获取它。具有完整路径的当前文件可用 - 但是如何在预处理器时间切断到该字符串的路径部分？这超出了我的技能范围。
所以，我的解决方案意味着客户端项目不需要多于我的API包装器库的依赖项，并且该库的主标题中的这一行：
#pragma comment(lib, "..\\3rd Party\\Wrapper API Library\\static.lib")
正如我所说，不必完善，但功能和合理的改进，而不必为每个客户端项目添加“额外的库目录”和“其他依赖项”字段。
这意味着如果我有两个这样的包装器，并希望在它们之间切换，我只需要更新我希望包含在我的客户端项目中的包装器，而不是更多。
更令人满意的！
如果有人有办法从预编译器（宏阶段）获取项目路径或文件的路径 - 那么请分享。然后这可能是完美的。
用户@evpo添加了这个answer here，看起来更优雅。
他的回答是有道理的，我在这里全文引用它：
除了项目属性中的链接库依赖项之外，还有另一种在Visual Studio中链接库的方法。
打开要与其他库组合的库（X）项目。添加您想要与X结合的其他库（右键单击，添加现有项...）。转到他们的属性并确保项目类型是库这将包括X中的其他库，就像您运行一样
lib /out:X.lib X.lib other1.lib other2.lib