DLL 文件复制到一个项目的 bin 目录，但不复制到另一个项目的 bin 目录？
我有一个包含 2 个项目的解决方案：ProjA 和 ProjB。 ProjA 是一个应用程序，而 ProjB 是一个库。 ProjB 还引用了其他 3 个 DLL 文件（C、D、E）。当我构建 ProjB 时，C、D 和 E 都进入 bin 目录。当我编译 ProjA （仅引用 ProjB）时，仅复制 C 和 D，而不复制 E。
我真的不确定什么会导致这种情况发生。我查看了引用属性，发现所有 3 个属性（C、D 和 E）都是相同的（名称和路径除外）。我想我不确定为什么 ProjB 会将 E 放入 bin 目录中，但是当我的应用程序（ProjA）构建时它不会在本地复制 E？
I have a solution with 2 projects in it: ProjA and ProjB. ProjA is an application while ProjB is a library. ProjB also references 3 other DLL files (C, D, E). When I build ProjB C, D, and E all go into the bin directory. When I compile ProjA (which ONLY references ProjB) only C and D are copied, and not E.
I'm really not sure what would cause this to happen. I looked at the reference properties and all 3 (C, D, and E) are identical (except for their name and path). I guess I'm not sure why ProjB would place E into the bin directory, but when my application (ProjA) builds it does not copy E locally?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我将在这里大胆猜测：项目 B 不直接使用引用 E，因此该引用不会出现在项目 B 输出的 PE 清单中。
可能您对项目 B 中的引用有“复制本地”，这解释了为什么这些程序集被复制到项目 B 的 bin 文件夹中。
但是，如果您要打开项目 B 的 dll，您会注意到引用 E 未列为程序集依赖性。 Visual Studio / MSBuild 无法推断项目 A 对程序集 B 的使用需要 E。
若要解决此问题，请在项目 B 中使用引用 E 的类或功能。
或者，让项目 A & B 将它们的程序集输出到一个公共文件夹。提示：在这种情况下关闭“复制本地”以提高构建性能。
更新：
我尝试了几种不同的方法来重现您的问题，但我得到的最接近的方法是来自此帖子表明这可能是路径探测问题。在提供的示例中，从 A 到 B 的引用是静态文件引用 (bin\Debug\ProjB.dll)，并且依赖项 (E) 定义为 Copy Local=False。示例项目的设置方式是所有依赖项都已编译并打包在 zip 中。
当您编译 A 时，您所描述的问题是显而易见的。修复方法应该是将 ProjB 的 E 引用更改为“Copy Local=True”，但是如果您进行此更改并重新编译 - 没有区别！为什么？
似乎更改设置“复制本地”实际上并没有以任何方式更改 ProjB 的输出。由于 ProjB 中的引用是静态引用，因此它不会检测到已发生任何更改。直到您执行 Clean 后，构建才会正常编译。
不知道这是否有帮助。否则，祝你好运。
I'm going to go out on a limb here and make a wild guess: reference E is not used directly by project B thus the reference does not appear in the PE manifest of project B's output.
Likely you have "Copy Local" on the references in Project B which explains why these assemblies are copied to the bin folder of project B.
However, if you were to open the dll for project B you will notice that reference E is not listed as an assembly dependency. Visual Studio / MSBuild cannot infer that Project A's usage of assembly B requires E.
To resolve the problem, use a class or feature of reference E in Project B.
Alternatively, have project A & B output their assemblies to a common folder. Tip: turn off "Copy Local" in this scenario to improve build performance.
Update:
I've tried several different ways to reproduce your problem but the closest I've got was from this post which suggests that it may be a path probing problem. In the example provided the reference from A to B is a static file reference (bin\Debug\ProjB.dll) and the dependencies (E) are defined as Copy Local=False. The sample project is set up in such a way that all the dependencies have been compiled and packaged in the zip.
When you compile A, the problem you've described is noticeable. The fix, should be to change ProjB's E reference to "Copy Local=True", but if you make this change and recompile -- there's no difference! Why?
It seems as though changing the setting "Copy Local" doesn't actually change the output of ProjB in any way. And because the reference in ProjB is a static reference, it doesn't pick up that any changes have occurred. It's not until you do a Clean that the build compiles normally.
Don't know if that helps. Otherwise, good luck.