在代码中不需要dummy 只是:

向可执行项目添加引用

或/并确保在可执行项目中的引用有“复制本地”设置为TRUE(这是我的“错误”)，似乎这“覆盖了”在基本引用库项目中的设置…

是的，您需要将“本地复制”设置为true。但是，我非常确定您还需要从主项目引用该程序集，并将Copy Local设置为true—它不仅仅是从依赖的程序集复制。

您可以通过单击References下的程序集并按F4来获得Copy Local属性。

在代码中不需要dummy 只是:

向可执行项目添加引用

或/并确保在可执行项目中的引用有“复制本地”设置为TRUE(这是我的“错误”)，似乎这“覆盖了”在基本引用库项目中的设置…

TLDR;Visual Studio 2019可能只是需要重新启动。

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

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

具体地说:

Project1: targets.netstandard2.1 通过Nuget引用Microsoft.Extensions.Logging.Console projec2: targets.netstandard2.1 通过项目引用引用Project1 Project2Tests: targets.netcoreapp3.1 通过项目引用引用Project2

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

我决定通过将Microsoft.Extensions.Logging.Console添加到Project2中来解决这个问题，结果发现Visual Studio的Nuget Manager并没有列出安装在Project1中的Microsoft.Extensions.Logging.Console，尽管它存在于Project1中。csproj文件。

简单地关闭并重新启动Visual Studio就解决了这个问题，而不需要添加额外的引用。也许这将为某人节省45分钟的生产力损失:-)

我发现，如果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的回答。

我有一个类似的问题，其中一个DLL我已经包括在项目作为内容和“复制始终”设置，没有被复制到bin文件夹。我通过在app.config中添加一个dependentAssembly引用来解决这个问题。