是的，您需要将 Copy Local 设置为 true . 但是， I'm pretty sure 您还需要从主项目引用该程序集并将 Copy Local 设置为 true - 它不仅仅是从依赖程序集中复制的 .
您可以通过单击 References 下的程序集并按F4来访问 Copy Local 属性 .
47
只是对霸王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);
}
}
这个信息实际上花了我几个小时来弄清楚，所以我想我分享它 .
0
当你使它成为一个组件属性时，它看起来很光滑
[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);
}
}
16 回答
您可以将主项目和ProjectX的构建输出路径设置为同一文件夹，然后您可以获得该文件夹中所需的所有dll .
除了上面常见的，我有一个多项目解决方案发布 . 显然有些文件针对不同的框架 .
所以我的解决方案：属性>特定版本（假）
这是对nvirth示例的轻微调整
NO NEED FOR DUMMY IN CODE
只是：
或/并确保可执行项目中的引用
"Copy Local"设置为TRUE（这是我的“错误”）似乎这个"overwrote"基础引用库项目中的设置...将DLL作为现有项添加到其中一个项目中，并应对其进行排序
我会将它添加到Postbuild事件，以将必要的库复制到输出目录 . 像XCopy pathtolibraries targetdirectory
您可以在项目属性 - >构建事件中找到它们 .
确保您使用的依赖dll没有比项目应用程序的目标.net框架更高的目标.net框架 .
您可以通过选择项目来检查，然后按ALT ENTER，然后从左侧选择Application，然后选择项目的Target Framework .
假设，依赖dll Target Framework = 4.0和Application dll Target Framework = 3.5然后将其更改为4.0
谢谢！
如果您正确单击引用的程序集，您将看到名为 Copy Local 的属性 . 如果Copy Local设置为true，则程序集应包含在bin中 . However ，接口是Visual Studio的一个问题，有时它不包含bin文件夹中引用的dll ...这是对我有用的解决方法：
我发现如果ProjectX引用了abc.dll但没有直接使用abc.dll中的任何DEFINED类型，那么abc.dll将不会被复制到主输出文件夹 . （它将被复制到ProjectX输出文件夹，使其更加混乱 . ）
因此，如果你没有在ProjectX中的任何地方明确使用abc.dll中的任何类型，那么在ProjectX中的一个文件中的某处放置一个虚拟声明 .
您不需要为每个类执行此操作 - 只需一次就足以使DLL复制并且一切都按预期工作 .
Addendum: 请注意，这可能适用于调试模式，但不适用于发布 . 有关详细信息，请参阅@nvirth的答案 .
是的，您需要将
Copy Local设置为true. 但是， I'm pretty sure 您还需要从主项目引用该程序集并将Copy Local设置为true- 它不仅仅是从依赖程序集中复制的 .您可以通过单击
References下的程序集并按F4来访问Copy Local属性 .只是对霸王Zurg的回答的旁注 .
我已经以这种方式添加了虚拟引用，并且它在调试模式下工作：
但在发布模式下，依赖的dll仍然没有被复制 .
然而，这有效：
这个信息实际上花了我几个小时来弄清楚，所以我想我分享它 .
当你使它成为一个组件属性时，它看起来很光滑
用法将是：
进入同样的问题 . 背景信息：在构建之前，我在解决方案中添加了一个新的Project X.项目Y依赖于项目X，项目A，B，C依赖于项目Y.
构建错误是无法找到项目A，B，C，Y和X dll .
Root cause was that newly created Project X targeted .NET 4.5 while the rest of the solution projects targeted .NET 4.5.1. 项目X没有构建，导致其他项目也没有构建 .
Make sure any newly added Projects target the same .NET version as the rest of the solution.
不确定这是否有帮助，但对我来说，很多时候我引用了一个DLL（当然会自动将它添加到bin文件夹中） . 但是，该DLL可能需要额外的DLL（取决于我正在使用的功能） . 我不想在我的项目中引用它们，因为它们只需要与我实际使用的DLL相同的文件夹 .
我通过“添加现有文件”在Visual Studio中完成此操作 . 除了Add_data文件夹之外，您应该可以将它添加到任何位置 . 我个人只是将它添加到根目录 .
然后将该文件的属性更改为...
Build Action = None（将此设置为内容实际上将“root”版本复制到根目录，再加上Bin中的副本） .
复制到输出文件夹=如果更新则复制（基本上只有在缺少时将其放在BIN文件夹中，但之后不执行）
当我发布时...我添加的DLL仅存在于BIN文件夹中而在Publish位置中没有其他地方（这就是我想要的） .
您还可以检查以确保您要查找的DLL未包含在GAC中 . 我相信，如果构建计算机上的GAC中已经存在这些文件，那么Visual Studio很聪明 .
我最近遇到过这种情况，我一直在测试一个需要在GAC中存在程序集的SSIS包 . 我已经忘记了这一点，并想知道为什么这些DLL在构建期间没有出现 .
要检查GAC中的内容（从Visual Studio Developer命令提示符）：
或者输出到文件以便于阅读：
要删除程序集：
我还应该注意，一旦我从GAC中删除了文件，它们在构建后正确地输出到\ bin目录中（即使对于根项目中没有直接引用的程序集） . 这是在Visual Studio 2013 Update 5上 .
在我的情况下，这是最愚蠢的事情，由我不同意的TFS / VS的默认行为引起 .
由于添加dll作为对主项目的引用不起作用，我决定将其添加为“现有项目”，复制本地=始终 . 即便如此，文件也不存在 .
事实证明，即使文件存在于VS解决方案上，并且所有内容都在本地和服务器上编译，VS / TFS也没有添加实际添加文件到源代码控制 . 它根本没有包含在“待定变更”中 . 我不得不手动转到Source Control Explorer并明确单击“Add items to folder”图标 .
愚蠢因为我在VS中已经发展了15年 . 我之前遇到过这种情况，我只是不记得了，不知怎的，我错过了它因为文件是常规引用所有仍然编译，但是作为现有项添加的文件没有被复制，因为它不存在于源控制服务器 .
我希望这能节省一些时间，因为我失去了2天的生命 .