我确定可能会发生一些我不太了解的事情，所以如果这是一个愚蠢的问题，或者有明显的问题，请原谅我细节遗失。
我有一个Visual Studio 2015解决方案，我已经从.NET 4.5.1升级到.NET 4.7.1。该解决方案包括一个网站（而不是Web应用程序）项目和几个库。这些库实际上没有任何依赖关系（彼此除外），当它们针对.NET 4.7.1时，它们不会使用，需要或引用.NETStandard.Library。
当我特别编译其中一个库时，它会将一堆.NET 4.7.1门户dll复制到网站bin文件夹中。遗憾的是，该网站是一个Kentico 11应用程序，并且它一直试图加载System.IO.Compression.ZipFile外观，并且因为它是一个参考程序集而不是真正的程序集而窒息它。
如果我删除.dll，一切运行正常......但我不想每次都删除它或添加一个post-build事件来删除它。那太傻了。
任何人都可以帮助我了解这里发生了什么，以及如何清理它？
答案 0 :(得分：2)
Kentico 11只能瞄准.NET 4.7，所以为了完全支持你的.NET 4.7.1库我相信它正在复制那些额外的外观DLL。这基于.NET 4.7.1发布公告，特别是本节：
BCL - .NET Standard 2.0支持
.NET Framework 4.7.1内置了对.NET Standard 2.0的支持。 .NET Framework 4.7.1添加了大约200个缺少的API，这些API是.NET Standard 2.0的一部分，但实际上并未由.NET Framework 4.6.1,4.6.2或4.7实现。您可以参考.NET标准Microsoft文档上的.NET标准的详细信息。
针对.NET Framework 4.6.1到4.7的应用程序必须部署其他.NET Standard 2.0支持文件才能使用.NET Standard 2.0库。出现这种情况是因为.NET Framework 4.6.1发布后.NET Standard 2.0规范已经完成。 .NET Framework 4.7.1是.NET Standard 2.0之后的第一个.NET Framework版本，使我们能够提供全面的.NET Standard 2.0支持。
https://blogs.msdn.microsoft.com/dotnet/2017/10/17/announcing-the-net-framework-4-7-1/
引用我得出这个结论的参考： https://github.com/Particular/NServiceBus/issues/5047#issuecomment-339096350
<强>更新
我无法在Visual Studio 2017版本15.6.2中重现您的问题。
我安装了针对.NET 4.7的Kentico 11网站项目。然后我创建了一个针对.NET 4.7.1的库项目。我在项目中添加了一些虚拟代码，以利用Sysetem.IO.Compression和System.Net.Http命名空间。我从Kentico添加了对该项目的引用并运行了一个版本。没有外观DLL复制到bin文件夹。
这篇文章表明在Visual Studio 15.6版https://github.com/dotnet/sdk/issues/1647#issuecomment-364999962
中修复了该问题答案 1 :(得分：1)
对程序集的引用有自己的属性。如果要将程序集复制到构建输出目录，则可以在此处指定。也许某处它被设置为true。要检查是否在Visual Studio中转到解决方案资源管理器并右键单击引用的程序集。然后单击“属性”并查找名为“复制本地”的属性。
答案 2 :(得分：1)
需要部署到bin文件夹的其他文件来支持在.NET Framework应用程序中引用和运行.NET Standard 1.x和.NET Standard 2.0库。
我们已经记录了这个as a known issues with .NET Framework 4.7.1。
然而，这些附加文件的存在是不够的。您还需要生成绑定重定向，以确保类型在库之间正确统一。
Visual Studio 15.6.3（及更高版本）进行了更改，将自动为您的应用程序生成这些绑定重定向。
.NET Framework 4.7.2解决了需要在应用程序中部署这些附加文件的问题。在.NET Framework 4.7.2上定位或运行时，您不会将任何其他文件复制到bin文件夹，也不会自动生成绑定重定向。
您可以按照here的说明尝试使用.NET Framework 4.7.2并查看新内容。