我会将它添加到Postbuild事件中，以将必要的库复制到输出目录中。比如XCopy pathtolilibraries targetdirectory

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

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

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

根本原因是新创建的项目X针对。net 4.5，而其余的解决方案项目针对。net 4.5.1。项目X没有建立，导致其他项目也没有建立。

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

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

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

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

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

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

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

这是对nvirth示例的轻微调整

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

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

所以我的解决方案:属性>特定版本(假)

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

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

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

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

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