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分钟的生产力损失:-)

您还可以检查以确保您正在寻找的dll不包含在GAC中。我相信Visual Studio很聪明，不会复制那些已经存在于构建机器的GAC中的文件。

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

要检查GAC中的内容(从Visual Studio开发人员命令提示符中):

gacutil -l

或输出到一个文件，使其更容易阅读:

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

移除一个组件:

gacutil -u MyProjectAssemblyName

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

这是对nvirth示例的轻微调整

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

如果右击引用的程序集，将看到名为Copy Local的属性。如果“本地复制”设置为true，则程序集应该包含在bin中。然而，Visual studio有一个问题，有时它不包括在bin文件夹中引用的dll…这是对我有效的变通方法:

在我的例子中，这是最愚蠢的事情，由TFS/VS的默认行为引起的，我不同意。

由于添加dll作为主项目的引用没有工作，我决定将其添加为“现有项”，复制本地=始终。即使那时文件也不在那里。

事实证明，即使文件出现在VS解决方案中，并且在本地和服务器上编译了所有内容，VS/TFS并没有将该文件添加到源代码控制中。它根本不包括在“未决更改”中。我不得不手动打开源代码管理资源管理器，并明确地单击“将项目添加到文件夹”图标。

愚蠢，因为我已经在vs中开发了15年，我以前遇到过这种情况，我只是不记得了，不知为何我错过了它，因为所有东西仍然编译，因为文件是常规引用，但被添加为Existing Item的文件没有被复制，因为它不存在于源代码控制服务器上。

我希望这能节省一些时间，因为我失去了2天的生命。

不确定这对我是否有帮助，但我多次引用DLL(当然会自动将其添加到bin文件夹中)。然而，DLL可能需要额外的DLL(取决于我使用的函数)。我不想在我的项目中引用那些，因为它们只需要在我实际使用的DLL相同的文件夹中结束。

我在Visual Studio中通过“添加一个现有文件”来实现这一点。您应该能够将它添加到除Add_data文件夹之外的任何地方。就我个人而言，我只是把它加到根上。

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

Build Action = None(将此设置为Content之类的内容实际上是将“根”版本复制到根，并在Bin中添加一个副本)。

复制到输出文件夹=如果更新则复制(基本上只在它丢失时才将其放在BIN文件夹中，但在那之后就不会这样做)

当我出版…我添加的DLL只存在于BIN文件夹中，而在发布位置(这是我想要的)中没有其他地方。