C# 依赖 DLL 没有被复制到 Visual Studio 中的构建输出文件夹

Dependent DLL is not getting copied to the build output folder in Visual Studio

提问by Brij

I have a visual studio solution. I have many projects in the solution. There is one main project which acts as the start up and uses other projects. There is one project say "ProjectX". Its reference is added to main project. The ProjectX references another .NET dll (say abc.dll) that isn't part of the solution.

我有一个视觉工作室解决方案。我在解决方案中有很多项目。有一个主要项目作为启动并使用其他项目。有一个项目说“ProjectX”。它的引用被添加到主项目中。ProjectX 引用了另一个不属于解决方案的 .NET dll（比如 abc.dll）。

Now this abc.dll should be copied to bin/debug folder of main project, but it isn't getting copied there. Why is it not getting copied, any known reasons ?

现在这个 abc.dll 应该被复制到主项目的 bin/debug 文件夹，但它没有被复制到那里。为什么它没有被复制，任何已知的原因？

回答by Mike Perrenoud

Yes, you'll need to set Copy Localto true. However, I'm pretty sureyou'll also need to reference that assembly from the main project and set Copy Localto trueas well - it doesn't just get copied from a dependent assembly.

是的，您需要设置Copy Local为true。不过，我敢肯定，你还需要从主体工程和一套装配参考Copy Local，以true以及-它不只是得到从依赖程序集复制。

You can get to the Copy Localproperty by clicking on the assembly under Referencesand pressing F4.

您可以Copy Local通过单击下面的组件References并按 F4来访问该属性。

回答by Overlord Zurg

I found that if ProjectX referenced the abc.dll but didn't directly use any of the types DEFINED in abc.dll, then abc.dll would NOT be copied to the main output folder. (It would be copied to the ProjectX output folder, to make it extra-confusing.)

我发现如果 ProjectX 引用了 abc.dll 但没有直接使用 abc.dll 中定义的任何类型，那么 abc.dll 将不会被复制到主输出文件夹。（它将被复制到 ProjectX 输出文件夹中，使其更加混乱。）

So, if you're not explicitly using any of the types from abc.dll anywhere in ProjectX, then put a dummy declaration somewhere in one of the files in ProjectX.

因此，如果您没有在 ProjectX 中的任何位置显式使用 abc.dll 中的任何类型，请在 ProjectX 中的某个文件中的某处放置一个虚拟声明。

AbcDll.AnyClass dummy006; // this will be enough to cause the DLL to be copied

You don't need to do this for every class -- just once will be enough to make the DLL copy and everything work as expected.

您不需要对每个类都这样做——只需一次就足以使 DLL 副本和一切按预期工作。

Addendum:Note that this may work for debug mode, but NOT for release. See @nvirth's answer for details.

附录：请注意，这可能适用于调试模式，但不适用于发布。有关详细信息，请参阅@nvirth 的回答。

回答by Darren Alfonso

Ran into this same issue. Background info: before building, I had added a new Project X to the solution. Project Y depended on Project X and Project A, B, C depended on Project Y.

遇到了同样的问题。背景信息：在构建之前，我在解决方案中添加了一个新的 Project X。项目 Y 依赖于项目 X，项目 A、B、C 依赖于项目 Y。

Build errors were that Project A, B, C, Y, and X dlls could not be found.

构建错误是无法找到项目 A、B、C、Y 和 X dll。

Root cause was that newly created Project X targeted .NET 4.5 while the rest of the solution projects targeted .NET 4.5.1.Project X didn't build causing the rest of the Projects to not build either.

根本原因是新创建的 Project X 以 .NET 4.5 为目标，而其余解决方案项目以 .NET 4.5.1 为目标。项目 X 未构建导致其余项目也未构建。

Make sure any newly added Projects target the same .NET version as the rest of the solution.

确保任何新添加的项目针对与解决方案的其余部分相同的 .NET 版本。

回答by YantingChen

You may set both the main project and ProjectX's build output path to the same folder, then you can get all the dlls you need in that folder.

您可以将主项目和 ProjectX 的构建输出路径设置为同一个文件夹，然后您就可以在该文件夹中获取您需要的所有 dll。

回答by nvirth

Just a sidenote to Overlord Zurg's answer.

只是 Zurg 大王回答的旁注。

I've added the dummy reference this way, and it worked in Debug mode:

我以这种方式添加了虚拟引用，它在调试模式下工作：

public class DummyClass
{
    private static void Dummy()
    {
        var dummy = typeof(AbcDll.AnyClass);
    }
}

But in Release mode, the dependent dll still did not get copied.
This worked however:

但是在 Release 模式下，依赖的 dll 仍然没有被复制。
然而，这有效：

public class DummyClass
{
    private static void Dummy()
    {
        Action<Type> noop = _ => {};
        var dummy = typeof(AbcDll.AnyClass);
        noop(dummy);
    }
}

This infomation actually costed me hours to figure out, so I thought I share it.

这些信息实际上花了我几个小时来弄清楚，所以我想我分享一下。

回答by Brett

You could also check to make sure the DLLs you're looking for aren't included in the GAC. I believe Visual Studio is being smart about not copying those files if it already exists in the GAC on the build machine.

您还可以检查以确保您要查找的 DLL 未包含在 GAC 中。我相信如果 Visual Studio 已经存在于构建机器上的 GAC 中，则不会复制这些文件是明智的。

I recently ran in this situation where I'd been testing an SSIS package that needed assemblies to exist in the GAC. I'd since forgotten that and was wondering why those DLLs weren't coming out during a build.

我最近遇到过这种情况，我一直在测试一个需要在 GAC 中存在程序集的 SSIS 包。我已经忘记了这一点，并想知道为什么这些 DLL 在构建过程中没有出现。

To check what's in the GAC (from a Visual Studio Developer Command Prompt):

要检查 GAC 中的内容（从 Visual Studio 开发人员命令提示符）：

gacutil -l

Or output to a file to make it easier to read:

或输出到文件以使其更易于阅读：

gacutil -l > output.txt
notepad.exe output.txt

To remove an assembly:

要移除装配体：

gacutil -u MyProjectAssemblyName

I should also note, that once I removed the files from the GAC they were correctly output in the \bin directory after a build (Even for assemblies that were not directly referenced in the root project). This was on Visual Studio 2013 Update 5.

我还应该注意，一旦我从 GAC 中删除了文件，它们就会在构建后正确输出到 \bin 目录中（即使对于在根项目中没有直接引用的程序集）。这是在 Visual Studio 2013 Update 5 上。

回答by Manish Jain

Make sure that the dependent dll used by you does not have target .net framework higher than the target .net framework of your project's Application.

确保您使用的依赖 dll 的目标 .net 框架不高于您项目应用程序的目标 .net 框架。

You can check this by selecting your project, then press ALT+ENTER, then select Application from left side and then select Target Framework of your project.

您可以通过选择您的项目来检查这一点，然后按 ALT+ENTER，然后从左侧选择应用程序，然后选择您项目的目标框架。

Suppose, dependent dll Target Framework = 4.0 and Application dll Target Framework = 3.5 then change this to 4.0

假设，依赖 dll Target Framework = 4.0 和 Application dll Target Framework = 3.5 然后将其更改为 4.0

Thank you!

谢谢！

回答by da_jokker

Not sure if this helps but for me, many times I reference a DLL (which automatically adds it to the bin folder of course). However that DLL might need additional DLLs (depending on what functions I'm using). I do NOT want to reference those in my Project because they just simply need to end up in the same folder as the DLL I am actually using.

不确定这是否有帮助，但对我来说，很多时候我引用了一个 DLL（当然它会自动将它添加到 bin 文件夹中）。但是，该 DLL 可能需要额外的 DLL（取决于我使用的函数）。我不想在我的项目中引用它们，因为它们只需要与我实际使用的 DLL 位于同一文件夹中。

I accomplish this in Visual Studio by "Adding an existing file". You should be able to add it anywhere except the Add_data folder. personally I just add it to the root.

我通过“添加现有文件”在 Visual Studio 中完成此操作。您应该能够将它添加到除 Add_data 文件夹之外的任何地方。我个人只是将它添加到根目录。

Then change the properties of that file to ...

然后将该文件的属性更改为...

Build Action = None (having this set to something like Content actually copies the "root" version to the root, plus a copy in the Bin).

Build Action = None（将此设置为类似 Content 的内容实际上会将“root”版本复制到根目录，以及 Bin 中的副本）。

Copy to output folder = Copy if Newer (Basically puts it in the BIN folder only if it is missing, but doesn't do it after that)

复制到输出文件夹 = 如果较新则复制（基本上只有在它丢失时才将其放入 BIN 文件夹中，但之后不会这样做）

When I publish.. my added DLL's only exists in the BIN folder and nowhere else in the Publish location (which is what I want).

当我发布时..我添加的 DLL 只存在于 BIN 文件夹中，而在发布位置（这是我想要的）中没有其他地方。

回答by RicL

Other than the common ones above, I had a multi-project solution to publish. Apparently some files target different frameworks.

除了上面的常见解决方案之外，我还有一个多项目解决方案要发布。显然有些文件针对不同的框架。

So my solution: Properties > Specific Version (False)

所以我的解决方案：属性>特定版本（错误）

回答by Cadburry

NO NEED FOR DUMMY IN CODE
Just :

无需代码中的 DUMMY
只需：

add a Reference to the Executeable Project

添加对可执行项目的引用

or/and ensure that the reference in the executeable project has "Copy Local"set to TRUE(which was my "fault") is seems that this "overwrote"the setting in the base referenced library-project...

或/并确保可执行项目中的引用已"Copy Local"设置为TRUE（这是我的“错误”）似乎这“覆盖”了基础引用库项目中的设置...