Question

我有一个visual studio解决方案。我在解决方案中有很多项目。有一个主要项目作为启动并使用其他项目。有一个项目说“ProjectX”。它的参考被添加到主项目中。 ProjectX引用了另一个不是解决方案的.NET dll（例如abc.dll）。

现在应该将此abc.dll复制到主项目的bin / debug文件夹中，但不会将其复制到那里。为什么不被复制，任何已知的原因？

Answer 1

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

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

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

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

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

Answer 2

只是对霸王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);
    }
}

这个信息实际上耗费了我几个小时才弄明白，所以我想我分享了它。

Answer 3

是的，您需要将Copy Local设置为true。但是，我非常确定您还需要从主项目中引用该程序集，并将Copy Local设置为true - 它不会被复制来自一个依赖集会。

您可以点击Copy Local下的程序集并按F4进入References属性。

Answer 4

当你把它作为一个装配属性时它看起来很光滑

[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))]

Answer 5

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

构建错误是找不到项目A，B，C，Y和X dll。

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

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

Answer 6

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

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

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

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

复制到输出文件夹=如果更新则复制（基本上只有在缺少BIN文件夹时将其放入BIN文件夹中，但之后不再执行）

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

Answer 7

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

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

检查GAC中的内容（来自Visual Studio Developer命令提示符）：

gacutil -l

或输出到文件以便于阅读：

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

删除程序集：

gacutil -u MyProjectAssemblyName

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

Answer 8

这是对nvirth示例的轻微调整

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

Answer 9

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

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

db.users.update_many({}, [
  {
    $set: {
      "registered.newField": {
        $year: {
          $dateFromString: {
            dateString: "$registered.date"
          }
        }
      }
    }
  }
]);

特别是：

<Project Sdk="Microsoft.NET.Sdk">：定位目标Project1
- 通过Nuget引用.netstandard2.1
Microsoft.Extensions.Logging.Console：定位目标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文件中的内容。

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

Answer 10

问题：

在生成输出不包含引用的DLL的NuGet程序包DLL（Newtonsoft.json.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/

Answer 11

在我看来，这是最愚蠢的事情，原因是我不同意TFS / VS的默认行为。

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

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

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

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

Answer 12

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

您可以在项目属性中找到它们 - ＆gt;建立活动。

Answer 13

如果你正确点击引用的程序集，你会看到一个名为复制本地的属性。如果Copy Local设置为true，则程序集应包含在bin中。然而，接口是Visual Studio的一个问题，有时候它不包含bin文件夹中引用的dll ......这是对我有用的解决方法：

Answer 14

VS2019 V16.6.3

对我来说，问题在于主.proj文件最终以这样的条目结束，该条目的DLL未被复制到父项目bin文件夹中。

<ProjectReference Include="Project B.csproj">
  <Project>{blah blah}</Project>
  <Name>Project B</Name>
  <Private>True</Private>
</ProjectReference>

我手动删除了<Private>True</Private>行，然后将DLL复制到了主项目的每个内部版本的主项目bin文件夹中。

如果在主项目的references文件夹中转到问题项目的引用，请单击它并查看属性，其中有一个“ Copy Local”设置。私有标签等于此设置，但是由于某些原因，更改本地副本对.proj文件中的私有标签没有影响。

令人讨厌的是，我没有更改参考的副本本地值，也不知道它是如何设置的，又浪费了一天的时间来追踪VS的一个愚蠢问题。

感谢所有其他可以帮助我确定原因的答案。

HTH

Answer 15

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

Answer 16

不需要代码中的虚假
只是：

添加对可执行项目的引用

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

Answer 17

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

所以我的解决方案：属性＆gt;具体版本（错误）

Answer 18

确保您使用的依赖dll没有比项目应用程序的目标.net框架更高的目标.net框架。

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

假设，依赖dll目标框架= 4.0和应用程序DLL目标框架= 3.5然后将其更改为4.0

谢谢！

Answer 19

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

依赖DLL未被复制到Visual Studio中的生成输出文件夹

19 个答案: