从属DLL不会复制到Visual Studio中的生成输出文件夹中

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

现在，应将此abc.dll复制到主项目的bin / debug文件夹中，但不会在此处复制它。任何已知原因为何未复制它？

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

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

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

您无需为每个类都执行此操作-只需一次就足以制作DLL复制，并且一切都能按预期工作。

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

只是Zurg霸主回答的注解。

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

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

但是在发布模式下，依存的dll仍然没有被复制。
但是，这可行：

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

这种信息实际上花了我几个小时才能弄清楚，所以我想我分享了。

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

您可以Copy Local通过单击下面的装配References并按F4 来进入属性。

将其设置为装配体属性时看起来很漂亮

[AttributeUsage(AttributeTargets.Assembly)]
public class ForceAssemblyReference: Attribute
{        
    public ForceAssemblyReference(Type forcedType)
    {
        //not sure if these two lines are required since 
        //the type is passed to constructor as parameter, 
        //thus effectively being used
        Action<Type> noop = _ => { };
        noop(forcedType);
    }
}

用法将是：

[assembly: ForceAssemblyReference(typeof(AbcDll.AnyClass))]

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

生成错误是找不到Project A，B，C，Y和X dll。

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

确保所有新添加的项目都与该解决方案的其余部分使用相同的.NET版本。

不确定是否有帮助，但对我而言，我多次引用DLL（当然会自动将其添加到bin文件夹中）。但是，该DLL可能需要其他DLL（取决于我使用的功能）。我不想在我的项目中引用它们，因为它们只需要与我实际使用的DLL放在同一文件夹中即可。

我在Visual Studio中通过“添加现有文件”完成此操作。您应该可以将其添加到Add_data文件夹以外的任何位置。我个人只是将其添加到根目录中。

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

Build Action = None（将其设置为类似Content的内容实际上将“ root”版本复制到root，再在Bin中复制一个副本）。

复制到输出文件夹=如果较新则复制（基本上仅在丢失时将其放在BIN文件夹中，但此后不这样做）

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

您还可以检查以确保所需的DLL不包含在GAC中。我相信Visual Studio在不复制那些文件（如果在构建计算机上的GAC中已经存在）方面很聪明。

我最近遇到这种情况，当时我正在测试一个SSIS程序包，该程序需要在GAC中存在程序集。从那以后，我就忘记了这一点，并且想知道为什么这些DLL在构建期间没有出现。

要检查GAC中的内容（通过Visual Studio Developer命令提示符）：

gacutil -l

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

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

要删除程序集：

gacutil -u MyProjectAssemblyName

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

就我而言，这是最愚蠢的事情，是由我不同意的TFS / VS的默认行为引起的。

由于添加dll作为对主项目的引用无效，因此我决定将其添加为“现有项”，并且“复制本地=始终”。即使那样，文件也不在那里。

事实证明，即使该文件存在于VS解决方案中，并且所有内容都在本地和服务器上进行了编译，VS / TFS都没有添加，实际上并未将该文件添加到源代码管理中。它根本没有包含在“待更改”中。我必须手动转到“源代码管理资源管理器”，并明确单击“将项目添加到文件夹”图标。

之所以愚蠢，是因为我在VS领域从事开发已有15年了。我之前碰到过这个问题，我只是不记得了，以某种方式我错过了它，因为由于文件是常规引用，所有内容仍在编译中，但是作为现有项添加的文件并未被复制，因为它不存在源代码控制服务器。

我希望这可以节省一些时间，因为我为此损失了两天的时间。

这是对nvirth的示例的轻微调整

internal class DummyClass
{
    private static void Dummy()
    {
        Noop(typeof(AbcDll.AnyClass));
    }
    private static void Noop(Type _) { }
}

我会将其添加到Postbuild事件中，以将必要的库复制到输出目录。类似于XCopy pathtolibraries targetdirectory

您可以在项目属性->构建事件中找到它们。

问题：

NuGet包DLL（Newtonsoft.json.dll）遇到类似的问题，其中生成输出不包含引用的DLL。但是汇编进行得很好。

固定：

在文本编辑器中浏览项目，并在其中查找带有标签的引用。像对还是错。“私人”是“复制本地”的同义词。在操作的某个位置，MSBuild会查找依赖关系，它是在其他位置找到您的依赖关系并决定不复制它。

因此，浏览每个.csproj / .vbproj文件并手动删除标签。重建，一切都可以在Visual Studio和MSBuild中工作。工作完成后，您可以返回并更新到您认为需要的位置。

参考：

https://www.paraesthesia.com/archive/2008/02/13/what-to-do-if-copy-local-works-in-vs-but.aspx/

代码中不需要傻瓜
只是：

添加对可执行项目的引用

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

如果右键单击引用的程序集，则将看到一个名为Copy Local的属性。如果“本地复制”设置为true，则程序集应包含在垃圾箱中。但是，Visual Studio似乎存在问题，有时它在bin文件夹中不包含引用的dll ...这是对我有用的解决方法：

TLDR；Visual Studio 2019可能只需要重新启动即可。

我在使用基于Microsoft.NET.Sdk项目的项目时遇到了这种情况。

<Project Sdk="Microsoft.NET.Sdk">

特别：

• Project1：目标 .netstandard2.1
  • Microsoft.Extensions.Logging.Console通过Nuget 引用
• Project2：目标 .netstandard2.1
  • 引用Project1通过项目引用
• Project2Tests：目标 .netcoreapp3.1
  • 引用Project2通过项目引用

在执行测试时，我收到错误消息，指出Microsoft.Extensions.Logging.Console找不到该错误消息，并且确实不在输出目录中。

我决定通过添加Microsoft.Extensions.Logging.Console来解决此问题Project2，只是发现Visual Studio的Nuget Manager未列出Microsoft.Extensions.Logging.Console安装位置。Project1的Project1.csproj文件，尽管该文件中存在该文件。

通过简单地关闭和重新启动Visual Studio即可解决此问题，而无需添加额外的引用。也许这可以为某人节省45分钟的生产力：-)

您可以将主项目和ProjectX的build输出路径都设置到同一文件夹，然后可以在该文件夹中获得所需的所有dll。

确保您使用的从属dll的目标.net框架没有高于项目应用程序的目标.net框架。

您可以通过选择项目，然后按ALT + ENTER，然后从左侧选择Application，然后选择项目的Target Framework来进行检查。

假设从属dll目标框架= 4.0，应用程序dll目标框架= 3.5，然后将其更改为4.0

谢谢！

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

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

将DLL作为现有项添加到项目之一中，并且应该对其进行排序