e.exe与我的自定义静态库c.lib相关联，后者使用w.dll中定义的Win32 API。 w.dll位于C：\ Windows \ System32中，其导入库为w.lib，位于Windows SDK目录中。 Shell w.lib在c.lib或e.exe项目中列为附加依赖？ （e.exe在两种情况下都能成功构建。）最佳实践是什么？为什么？我想e.exe不应该知道w.lib。
c.lib仅供一组开发人员共享（不会发送给客户）。
TEST ：我使用VS2008和dumpbin实用程序来测试这两种情况，结果如下：
w.lib在c.lib项目中添加为附加依赖。 dumpbin /archivemembers c.lib输出会将w.dll和。{1}}项目中的.obj文件中的偏移列为档案成员。
c.lib未在w.lib但c.lib项目中添加其他相关性：这次，dumpbin输出只包含e.exe的.obj文件，c.lib的大小小于案例1
（c.lib在c.lib项目中作为附加依赖添加在两种情况下。）
注意：我在这里使用w.exe和w.lib作为Windows库的虚构通用名称，但它们可以是例如Userenv.lib和Userenv.dll或Version.lib和Version.dll ...
答案 0 :(得分：1)
我认为你误解了创建档案和导入档案的内容。
正如您在评论中正确推荐的那样，创建一个存档，创建一个包含已编译的.objs的统一文件。现在，它可以包含您喜欢的任何代码，包括但不限于对库的动态调用。导入库是一个包含一个专门进行此类调用的obj的库，其想法是通过导入它，您的exe可以找到相应的符号（它们必须位于您创建的可执行文件中）。
从c.lib创建w.lib的过程只会提取w.lib的对象，并将它们附加到c.lib中的对象集合中。实际上，c.lib成为导入库+代码。
我认为你应该这样做吗？不是 - 它可能会导致e.exe所依赖的混淆;我认为你应该明确地将其显示为可见而不是试图隐藏它。也就是说，这只是建议而非规则。
答案 1 :(得分：0)
库没有链接，因此任何使用.lib的项目也需要它的依赖项。
基本上.lib在链接期间被“复制”到你的exe。
如果你想避免你的用户明确链接w.lib链接，在dll中转换c.lib，dll是链接的，你在构建期间不需要它们的依赖。