Runtime: 无法加载文件或程序集“ netfx.force.conflicts”

@ericstj您知道什么是“ netfx.force.conflicts”吗？

您好，当我尝试运行.NET Framework ASP.NET应用程序时遇到了同样的问题。 我需要卸载.NET Core 2.0 SDK吗？

@weshaggard

我找到了解决方案：删除Web应用程序下的bin文件夹，然后全部重建。

对我来说，当我通过Visual Studio 2017 15.3在调试中运行该应用程序时，该应用程序可以工作，但是当我将其发布到IIS正在查看的文件夹中时，该应用程序将无法正常工作。

最终我使它工作了，这是我尝试过的事情：

• 发布前删除bin和\ obj文件夹
• 删除我发布到的文件夹
• 重置IIS
• 确保将ApplicationPoolIdentity的.NET CLR版本设置为“无托管代码”

你知道什么是“ netfx.force.conflicts”吗？

它是一个立面，它引用了桌面中收件箱中的每个合同组件： https :

它只是一个ReferenceAssembly，切勿进入应用程序的输出目录。 该程序集没有对应的库，因为它没有typedef，并且永远不会出现在运行时程序集闭包中。

   System.Reflection.Assembly.Load(String assemblyString) +34
   System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective) +48

[ConfigurationErrorsException: Could not load file or assembly 'netfx.force.conflicts' or one of its dependencies. Reference assemblies should not be loaded for execution.  They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058)]
   System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective) +771
   System.Web.Configuration.CompilationSection.LoadAllAssembliesFromAppDomainBinDirectory() +256
   System.Web.Configuration.CompilationSection.LoadAssembly(AssemblyInfo ai) +58
   System.Web.Compilation.BuildManager.GetReferencedAssemblies(CompilationSection compConfig) +236

查看该调用栈，看来Asp.NET可能正在做一些不寻常的事情，在我看来，它就像是试图加载引用程序集以执行代码。 只要存在带有ReferenceAssemblyAttribute的程序集，该操作就会失败。 @pranavkm @DamianEdwards这对您来说合适吗？

@pranavkm你可以看看吗？ 这可能需要转到System.Web人员。

@pranavkm如果可以的话，您可以移植到aspnet

@danmosemsft这将用于System.Web，它不在GitHub上，仅在TFS中。 一旦看到了这里发生的一切，如果我们不能立即解决，我们将转到System.Web（与ASP.NET Core团队不同的人）。

我不太清楚程序集如何到达输出目录。 @alfeg \ @oldrev \ @ chris313​​89您能否共享应用程序的csproj或可能的repro步骤\ application？

@Eilon-啊，你说的很对。

我们看到了同样的问题。 我们有引用.NET Standard 1.6项目的.NET 4.7 ASP.NET项目，全部使用PackageReference 。 删除bin和obj并进行重建摆脱了警告，但随后我遇到了一个不同的YSOD：

[FileLoadException: Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]

[FileLoadException: Could not load file or assembly 'System.Runtime, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]

这可能是一个单独的问题，但是在Visual Studio 15.2和关联的工具中并没有发生。

对于我们的构建服务器，我已经通过从15.2跨MSBuild目录复制来“修复”了该问题，因为似乎无法通过安装程序进行降级。

@pranavkm我的项目
实际上，对bin / obj文件夹的深入了解有助于解决问题，但正如@Quppa所写，“ System。*”包的程序集重定向很多。 希望运行15.2版本的VS的第二个实例能够构建项目而不会出现问题，并且对vs的不完整更新不会对我造成太大阻碍。

在_non_-Core .NET 4.6.2 / 4.7项目（即完整的.NET Framework）以及Visual Studio 2017 Community Edition中，我也突然遇到了此问题。

我的猜测是我正在使用的某些NuGet软件包已更新，并且（偶然地）引入了.NET Core。

可能不相关：将所有NuGet软件包升级到最新版本后，我的参考文献列表中也出现了大量的感叹号：

当具有最大的构建日志详细程度时，我会发现类似以下内容的行：

主要参考文献“ System.Security.Cryptography.X509证书，版本= 4.1.2.0，区域性=中性，PublicKeyToken = b03f5f7f11d50a3a”。 （TaskId：21）
1>解析的文件路径为“ C：\ Program Files（x86）\ Microsoft Visual Studio \ 2017 \ CommunityMSBuild \ Microsoft \ Microsoft.NET.Build.Extensions \ net461 \ ref \ System.Security.Cryptography.X509Certificates.dll”。 （TaskId：21）
1>在搜索路径位置“ {RawFileName}”中找到引用。 （TaskId：21）
1>此引用不是“ CopyLocal”，因为至少一个源项目的“ Private”设置为“ false”，并且没有源项目的“ Private”设置为“ true”。 （TaskId：21）
1>此参考的ImageRuntimeVersion是“ v4.0.30319”。 （TaskId：21）

我不知道为什么对这个“ System.Security.Cryptography.X509Certificates”程序集的“ packages.config”引用实际上没有从NuGet下载的“ packages \ System.Security.Cryptography.X509Certificates.4.3.0 \ lib”中获取\ net461“文件夹，而是在MSBuild文件夹中查找。

@UweKeim我有同样的问题。 我有The referenced component 'System.Security.Cryptography.X509Certificates' could not be found. Draycir.Approvals.WebApi负载及其暗示的大量重定向。

@ chris313​​89是否有办法在解决方案资源管理器中的黄色感叹号⚠️后面获取实际的错误消息？

@UweKeim据我所知。 我得到的消息来自构建输出。

/ cc @weshaggard @ericstj可能有见识的人。

/ cc @dsplaisted这是对

@Quppa要修复这些警告，应应用所有建议的绑定重定向。 那应该解决YSOD。 对于具有web.config的项目，这意味着在错误窗口中双击警告，然后让VS修改您的web.config。 对于app.config，您可以启用自动bindingRedirects，它们将在构建时自动写入app.config。

@UweKeim检查错误列表的警告选项卡。 您可能会看到@Quppa提到的相同的重定向警告，应用重定向将解决它们。 编辑：您可能正在点击https://github.com/dotnet/sdk/issues/1499

@ericstj谢谢-添加重定向确实解决了YSOD。 我很困惑为什么在使用15.2构建解决方案时为什么我们没有得到相同的错误。

@danmosemsft \ @ericstj我能够（不一致地）使用repro应用https :

1）清理仓库
2）在VS中启动sln
3）在不更改启动项目的情况下，按Ctrl-F5。

我将在@HongGit中循环查看是否还有其他可以从BuildManager端解决的问题。

欢迎使用DLL地狱。 当Microsoft模仿Java Maven世界时，就会发生这种情况。 我一直讨厌Java的一件事。 .NET曾经是高级软件，但是由于NuGet的出现，现在我们处于DLL地狱。

对我来说，无论我做什么，黄色的感叹号仍然存在。

令我惊讶的是，否则我的项目似乎可以正常运行。

@UweKeim可以看到我在SDK存储库中打开的链接问题（包括解决方法）。 我认为这就是您要达到的目标。

很棒的支持@ericstj ，非常感谢。 这实际上起到了作用！ （尽管我不知道这实际上是做什么的😕）

如果将来不再需要该解决方法，将其保留在我的CSPROJ文件中是否会对您造成危害？

解决步骤

链接的解决方案要求将以下内容添加到CSPROJ文件中：

<Target Name="UpdateOriginalItemSpecs" AfterTargets="ResolveAssemblyReferences">
    <ItemGroup>
        <ReferencePath>
            <OriginalItemSpec>%(ReferencePath.FileName)</OriginalItemSpec>
        </ReferencePath>
    </ItemGroup>
</Target>

有时，添加到CSPROJ文件中还需要更多。 我的工作CSPROJ最后添加了以下内容：

<Target Name="UpdateOriginalItemSpecs" AfterTargets="ResolveAssemblyReferences">
  <ItemGroup>
    <ReferencePath>
      <OriginalItemSpec>%(ReferencePath.FileName)</OriginalItemSpec>
    </ReferencePath>
  </ItemGroup>
</Target>
<Target Name="ReplaceNetFxNetStandardRefWithLib" AfterTargets="ImplicitlyExpandNETStandardFacades">
  <ItemGroup>
    <Reference Remove="@(_NETStandardLibraryNETFrameworkReference)" Condition="'%(FileName)' != 'netfx.force.conflicts'" />
    <Reference Include="@(_NETStandardLibraryNETFrameworkLib)">
      <Private>true</Private>
    </Reference>
  </ItemGroup>
</Target>
<Target Name="RemoveNetFxForceConflicts" AfterTargets="ResolveAssemblyReferences">
  <ItemGroup>
    <ReferencePath Remove="@(ReferencePath)" Condition="'%(FileName)' == 'netfx.force.conflicts'" />
  </ItemGroup>
</Target>
<Target Name="RemoveNetFxForceConflicts" BeforeTargets="BuiltProjectOutputGroupDependencies">
  <ItemGroup>
    <ReferencePath Remove="@(ReferencePath)" Condition="'%(FileName)' == 'netfx.force.conflicts'" />
  </ItemGroup>
</Target>

还帮助我的是，将项目从.NET 4.7切换回了4.6.2之类的较低版本。

这还需要编辑所有“ packages.config”文件，并将“ net47 ”替换为“ net462 ”，然后在VS的Package Manager控制台中发出以下命令：

Update-Package -Reinstall

最后，我还需要删除/bin和/obj文件夹以及“ C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \”中的临时ASP.NET文件夹。临时ASP.NET Files \ temp”。

@UweKeim很高兴为您工作。 它的作用是欺骗IDE，使他们认为替换您的项目条目的引用实际上来自项目。 希望我们能够获得SDK来修复此错误。 FWIW即使在project.json nuget东西中也存在相同的错误，但是这种错误很少见。 解决方法通常是无害的，但是如果您碰巧在项目本身中具有全路径引用，也可能导致相同的问题。 如果我们希望它的作用范围更大，我们可以改进解决方法以使其不具有该行为。

@pranavkm我看到了。 msbuild日志不显示正在发生的复制。 实际上，msbuild的SLN的构建无法复制。 从VS构建：对我来说100％。 我对它进行了检举，然后看到了复制发生在devenv.exe进程中（不是msbuild，尽管我确实看到了MSBuild跟踪，所以可以肯定它是进程外生成）。 我没有从procmon中获得良好的调用栈，因此将需要调试VS来获取真正的罪魁祸首。 我怀疑有一些ASP.NET组件负责调试站点，因此如果有人可以从该端介入并提供帮助，将非常高兴。

更正，它不是复制副本的VS中构建的，而是debug 。 更新的procmon给了我一个堆栈，这是罪魁祸首：

24  mswebprj.dll    VspCopyFile + 0x70, f:\dd\src\vscommon\projutil\pu_file.cpp(1312)   0x1ced250b  C:\Program Files (x86)\Microsoft Visual Studio\IntPreview\Enterprise\Common7\Packages\mswebprj.dll
25  mswebprj.dll    CLangReferenceManager::DoCopyFile + 0x37, f:\dd\src\venus\project\langproj\langrefmgr.cpp(1127) 0x1cf9dd1d  C:\Program Files (x86)\Microsoft Visual Studio\IntPreview\Enterprise\Common7\Packages\mswebprj.dll
26  mswebprj.dll    CCopyProjectReference::CopyOneFile + 0x36, f:\dd\src\venus\project\langproj\langblddepnd.cpp(2170)  0x1cf9d110  C:\Program Files (x86)\Microsoft Visual Studio\IntPreview\Enterprise\Common7\Packages\mswebprj.dll
27  mswebprj.dll    CCopyProjectReference::CopyDeployDependencies + 0x3e7, f:\dd\src\venus\project\langproj\langblddepnd.cpp(1745)  0x1cf9c578  C:\Program Files (x86)\Microsoft Visual Studio\IntPreview\Enterprise\Common7\Packages\mswebprj.dll
28  mswebprj.dll    CCopyProjectReference::CopyProjectReference + 0xb7, f:\dd\src\venus\project\langproj\langblddepnd.cpp(1512) 0x1cf9be51  C:\Program Files (x86)\Microsoft Visual Studio\IntPreview\Enterprise\Common7\Packages\mswebprj.dll
29  mswebprj.dll    CProjectContext::UpdateSolution_EndLastUpdateAction + 0x5c, f:\dd\src\venus\project\langproj\webprojectcontext.cpp(975) 0x1cf44f89  C:\Program Files (x86)\Microsoft Visual Studio\IntPreview\Enterprise\Common7\Packages\mswebprj.dll
30  mswebprj.dll    CLangPackage::UpdateSolution_EndLastUpdateAction + 0x2d, f:\dd\src\venus\project\langproj\langpkg.cpp(3765) 0x1cf1c2b0  C:\Program Files (x86)\Microsoft Visual Studio\IntPreview\Enterprise\Common7\Packages\mswebprj.dll

@Eilon / @pranavkm您知道谁拥有mswebprj.dll吗？ 似乎不尊重Private / CopyLocal = false

@金华菲，你能看看吗？

我的发现/尝试错误修复-只是更新了VS.NET-没有更改框架版本（.NET 4.7），也没有更新nuget或其他任何东西：

• 删除bin文件夹-甚至ASP.NET卷影副本%temp%\Temporary ASP.NET Files
• 从web.config中删除所有dependentAssembly ，然后：
• 在Package Manager控制台中执行Update-Package -reinstall
• 2 x在警告对话框中单击（我的web.config中现在有80（!!） bindingRedirect ）
• 我手动删除了所有黄色引用/删除了它们-尽管构建和运行时都可以正常工作（？！）
• 我必须通过编辑.csproj文件从2个项目中手动删除NETStandard.Library 。 这些项目有一些胡扯Microsoft.CodeAnalysis.Common -可能（曾经）是罪魁祸首。
• 现在重新发布显示了添加到解决方案中的其他64个DLL文件-其中大多数是影子/重定向DLL和一个新的netstandard.dll

很高兴拥有：一种将现有项目转换为使用PackageReference而不是packages.config -也许可以稍微帮助nuget DLL地狱:)另外，在构建过程中使用2 x单击功能-我认为这应该是您的当面提示！ :)

@AndersMad还有一种很好的方法是在发生这种情况时安装特定（旧）版本的VS2017。 我尽力使用System Restore尝试恢复我的15.2安装，但是这只是使产品处于中断状态。

@Quppa是的，恕我直言，恕我直言，Microsoft不为Visual Studio的旧版本（如15.2）提供安装程序。 走“软件即服务”的方式。 在遇到严重错误后，我浪费了一天半的时间试图降级。 我也尝试了系统还原。 这导致VS显示空白屏幕。 我不得不撤消系统还原，无法将15.0升级到小于15.3的版本。 考虑到DLL现在的工作原理，我很可能将刚刚升级到EF Core 2的项目降级到1.1。 我认为像JSON配置文件惨败之类的问题现在可以解决。 显然，我需要第二台计算机来预先测试所有这些东西。 .NET Core的发行软件充其量是beta。

我也遇到了这个问题，在构建干净后一切正常。 但是，如果我在带有reshaper的VS中运行任何测试，则会弹出Could not load file or assembly 'netfx.force.conflicts' 。

@mscrivo是Web项目还是其他项目？ 我想确保我们能够跟踪所有发生这种情况的情况。

我为人们提供了一种解决方法，可以将以下内容添加到您的项目文件中，或者如果您愿意，可以将以下内容添加到您的项目文件导入的一些通用目标文件中：

<Target Name="RemoveNetFxForceConflicts" AfterTargets="ResolveAssemblyReferences">
  <ItemGroup>
    <ReferencePath Remove="@(ReferencePath)" Condition="'%(FileName)' == 'netfx.force.conflicts'" />
  </ItemGroup>
</Target>

我还在sdk存储库中提交了一个错误，以跟踪产品中的此修复程序： https :

是的，我所看到的所有Web项目。

2017年8月17日星期四，下午12:11埃里克·圣约翰[email protected]写道：

@mscrivo https://github.com/mscrivo是一个Web项目或其他东西
不同？ 我想确保我们能够追踪所有情况
这发生在哪里。

我有解决此问题的方法，将以下内容添加到您的
项目文件，或项目文件导入的某些通用目标文件（如果有）
你比较喜欢：

我还在sdk存储库中提交了一个错误，以跟踪在
产品：dotnet / sdk＃1509 https://github.com/dotnet/sdk/issues/1509

—
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/dotnet/corefx/issues/23229#issuecomment-323119376 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAQ0RMlJTwc00N2nB6_u7xSLhs6m64-Nks5sZGV4gaJpZM4O28QO
。

@ericstj尝试了这种解决方法，但似乎并未删除该文件。 我将其放置在项目文件的底部，在标记之前，对吗？

首先删除文件。 解决方法仅阻止Web项目系统对其进行复制。 您必须先删除它：只需删除bin文件夹。

知道了谢谢。

我已将解决方法添加到我们的Web项目中，但是在调试测试项目时，仍然以Web bin文件夹中的dll结尾。 是否也需要参加测试项目？

/ cc @BillHiebert ，他在Web项目系统中查看了此问题。 我的理解是任何Web项目都需要它。 @BillHiebert您可以共享此问题适用的项目类型指导吗？

这适用于网站项目（无msbuild项目文件）和Web应用程序项目。 包含Guid类型的项目{349c5851-65df-11da-9384-00065b846f21}

@UweKeim @ericstj我遇到了完全相同的问题，这使我无法将许多依赖项（例如Microsoft.AspNetCore.DataProtection）更新到最新的2.0版本。 :(必须回滚，然后等待MS修复。

我的Web项目中有“ RemoveNetFxForceConflicts”解决方法，但是此错误每隔30分钟左右就会再次出现。 我必须不断删除\bin\并进行重建。

解决方法不起作用。 我已将其添加到我们所有的项目中，并使用{349c5851-65df-11da-9384-00065b846f21}项目类型guid，它仍然位于我们的bin文件夹中。 接下来，我将尝试将其添加到我们所有的项目中。

您可以改用这种方法，在某些情况下，由于存在多个设置ReferencePath的目标（例如：DesignTimeRAR），因此可能没有运行先前的目标。

<Target Name="RemoveNetFxForceConflicts" BeforeTargets="BuiltProjectOutputGroupDependencies">
  <ItemGroup>
    <ReferencePath Remove="@(ReferencePath)" Condition="'%(FileName)' == 'netfx.force.conflicts'" />
  </ItemGroup>
</Target>

如果这不起作用，那么我们可能会有不止一种情况，即使用工具将非复制本地引用复制到输出。

@ericstj我会

有谁知道微软是否计划发布针对此问题的官方修补程序，以使开发人员不必在项目文件中乱搞？ 这让我感到奇怪，微软是否在.NET Framework上进行测试，还是只是假设我们都将立即切换到.NET Core。 您好，Microsoft，如果您正在听，则大多数客户仍在.NET Framework上。 如果您在该平台上进行测试以确保一切正常，那么这不会有什么坏处。 这与JSON项目文件发生的事情相同。 就个人而言，我感到惊讶的是，从2.0版开始，这仍然是一个问题。 我只需要提醒自己，出于所有实际目的，这是Beta版软件。 稳定并接近可用的1.0产品可能还要再过一年左右。

该修复程序无法立即交付。 我提供的解决方法是人们现在可以使用的，而拥有该组件的团队则有机会进行调查和修复。 我们已经在从两个不同的角度来解决此问题：Web项目系统错误地复制文件； SDK正在添加此文件NETFramework项目，包括那些无法将其修复到Web上的VS版本的项目。项目系统。 我很抱歉，如果从这个问题是在图书馆回购目前尚不清楚：我们正在计划出货修复。

我还将注意到，此错误是由于将2.0版本的.NETStandard2.0重新带到.NET Framework 4.6.1而进行的工作的结果。 它是一个崭新的功能。 我们听说过有关.NET Framework的信息，我们正在尝试将更多内容带入桌面：这就是其中之一。 我同意缺乏台式机的测试范围：这需要改进。 台式机特别困难，因为我们试图通过许多VS版本吸引客户，这些版本具有许多使用该工具的非常不同的项目和技术。 我确实要感谢@alfeg ， @UweKeim ， @mscrivo和@pranavkm等人，以及其他人帮助我们

@ericstj很高兴提供帮助。 说到这一点，您提供的最新变通办法也不起作用，只是构建并出现了相同的错误。

在构建之前是否清理了输出？ @BillHiebert在这里

@ericstj是的，我在项目文件中已经有一个

@BillHiebert在电子邮件中提到：

This copy  code only runs for WAP style web projects when one of its dependent projects is being built but not the web application project. If the web application project is being built as well this code path is skipped.

因此，基于此，我认为将变通办法应用于所有项目中是正确的。 从Bill的解释中，听起来好像Web项目的项目系统dll正在检查其依赖项的引用，这些引用不一定是Web项目。

好的，我还没有做..决定先尝试第二种解决方法。 那我应该把原始文件放到我们所有的项目文件中吗？

第二个是更有针对性的，所以我会用它。 如果您想以更简洁的方式将其添加到所有项目中，可以将其放入目标文件中，然后将其导入每个项目中。

安装vs2107 15.3之后，我在ASP.net MVC应用程序中遇到此问题==>无法加载文件或程序集'netfx.force.conflicts'

解决：

删除/ bin和/ out并删除非常重要的％temp％\ Temporary ASP.NET

@ericstj自从将解决方法应用于所有csproj文件以来，我们团队中没有人遇到此错误。 谨慎乐观地解决了这个问题。 如果再次出现，我会通知您。

将解决方法应用于解决方案工作中的每个项目后，构建所有Web项目时。 生成任何库项目时，请在解决方案中所有Web项目的bin文件夹中覆盖System。*程序集，并在随机System。*程序集上错误BadImageFormatException

@ericstj将工作放在项目文件中的位置无关紧要吗？

<Target Name="RemoveNetFxForceConflicts" 
BeforeTargets="BuiltProjectOutputGroupDependencies">
  <ItemGroup>
    <ReferencePath Remove="@(ReferencePath)" Condition="'%(FileName)' == 'netfx.force.conflicts'" />
  </ItemGroup>
</Target>

@ philip-reed不，据我所知没有关系。 但是我不确定100％。

我们的团队与@ijsgaus有相同的问题。 真烦人。 现在，我告诉他们只是再次删除obj和bin文件夹...

如果您使用标准2.0项目-双重定位可以解决问题。 我不检查nuget安装软件包。 作为临时解决方案。

遇到同样的问题，解决方法是删除该文件。 是否有可能在永久性修复程序上更新状态？

同样在这里。 没有工作的乐趣。 每次构建后都必须删除netfx dll实在很烦人。

我将库降到了netstandard1.3 ....，并设法删除了mvc依赖项，它现在似乎可以工作了。

我很好奇为什么@ericstj在https://github.com/dotnet/corefx/issues/23229#issuecomment -323119376中的解决方案不适用于人们。 关键是将其添加到解决方案中的所有项目中，而不仅仅是Web项目。 一旦这样做，我们已经有一个多星期没有看到这个问题了。

@ericstj ， @mscrivo我已经从https://github.com/dotnet/corefx/issues/23229#issuecomment -323119376和https://github.com/dotnet/corefx/issues/23229#issuecomment -324959465都应用了解决方法。 / bin文件夹中没有netfx.force.conflicts，但它会抱怨其他参考dll（如System.Data.Common和System.Diagnostics.StackTrace），但具有相同的错误：

[BadImageFormatException: Could not load file or assembly 'System.Data.Common' or one of its dependencies. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058)] System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) +0 System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) +457 System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection) +110 System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) +22 System.Reflection.Assembly.Load(String assemblyString) +34 System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective) +48

我还能尝试删除那些参考程序集或使那些参考程序集不复制到bin文件夹中吗？

我进行了更多调查，发现在构建Web项目时它可以正常工作。 但是，当我在构建Web项目后构建它引用的项目之一时，从上面得到了错误。 特别是它使我的测试失败。 有什么线索吗？ 我已将修复程序应用于解决方案中的所有项目。 并且所有人都使用PackageReference来获取NuGet。

@ andrii-litvinov我们有同样的问题。 当您重建基础项目而不构建Web项目时，它会将程序集的“错误”版本复制到Web bin目录中。 通过比较“已知有效” bin目录的副本来确认这一点。 由于未构建Web项目，因此无法执行解决方法ref / lib修复目标。

为了解决这个问题，我手动将web.config中几个程序集的绑定重定向调整为GAC中的版本newVersion="4.0.0.0" 。 我通过加载站点并为引起错误的程序集进行了更新，一一找到了这些错误。 在我们的例子中是5个程序集，但是我希望这可能会因您的项目而有所不同：

• 系统反射
• 系统运行时
• System.Runtime.Extensions
• System.Runtime.InteropServices
• System.Xml.ReaderWriter

Visual Studio会发出有关这些绑定重定向的警告，但我已指示我的团队暂时忽略它们。

@jeremyhayes感谢您分享您的解决方法！ 对于GAC中存在的程序集，它工作得很好，但是在我的情况下，System.Data.Common不在GAC中，因此此解决方案不起作用。 我试图了解这些程序集的来源，因为它们的大小较小（30KB，而编译Web应用程序时为150KB），以及可能的解决方法。

程序集来自“ C：\ Program Files（x86）\ Microsoft Visual Studio \ 2017 \ EnterpriseMSBuild \ Microsoft.NET.Build.Extensions”（vs2017）或“ C：\ Program Files（x86）MSBuild \ Microsoft \ Microsoft”。 NET.Build.Extensions”（旧版VS）或“ C：\ Program Files \ dotnet \ sdk \ 2.0.0 \ Microsoft \ Microsoft.NET.Build.Extensions”（dotnet cli）。

“ ref”文件夹下的程序集是较小的版本：它们是不包含任何实现的引用程序集，仅包含我们公共API的元数据。 “ lib”文件夹中的程序集是实际的实现程序集。

当您重建基础项目而不构建Web项目时，它将程序集的“错误”版本复制到Web bin目录中。 通过比较“已知良好”的bin目录的副本来确认这一点。 由于未构建Web项目，因此无法执行解决方法ref / lib修复目标。

是的，这就是@BillHiebert在Web项目系统中修复的错误。 它在不应该复制参考程序集的情况下，因为它没有注意到它们设置了copylocal = false。 尽管修复了Web项目系统中的问题，我们仍然需要对添加参考程序集的目标进行更改，因为项目系统更新不会无处不在，并且我们发现了更多尝试使用其他桌面构建工具的案例加载参考程序集以执行。

为了解决这个问题，我在web.config中手动将多个程序集的绑定重定向调整为GAC中的版本newVersion =“ 4.0.0.0”。

这将破坏依赖于更高版本中添加的API的任何人。 GAC中的那些将丢失添加到程序集中的API或typeforwards。

我们正在为此进行更好的修复，请参阅： https :

@ericstj谢谢您的快速答复和详细说明。 @jeremyhayes，通过@ericstj中提供@ijs​​gaus解决方案https://github.com/dotnet/corefx/issues/23439#issuecomment -323855505为我工作。 我意识到，这是一种临时解决方案，直到MS创建更好的解决方案为止，但它仍然有助于在Full Framework Web应用程序上继续使用.NET Standard 2.0。

尝试执行发行版本时，我在Web应用程序项目中遇到类似的问题-但奇怪的是，当我进行调试版本时，没有。 我已经尝试了上面列出的各种修复程序，但并不高兴。 有什么建议么？
试图以错误的格式加载程序集：C：\ Program Files（x86）\ Microsoft Visual Studio \ 2017 \ CommunityMSBuild \ Microsoft \ Microsoft.NET.Build.Extensions \ net461 \ ref \ netfx.force.conflicts。 dll文件
编辑：找到原因...发行版必须一直在尝试生成序列化程序集，而调试没有（都设置为auto） https://github.com/dotnet/standard/issues/418

@DaleKBurrell您是否尝试了我总结的步骤？

当然可以-但是我找到了原因，并将其添加为我的原始评论的编辑内容。 感谢回复。

我也对此事进行了调查并浪费了很多时间。
当MSBuild认为您对.NetStandard有依赖性时，它基本上就开始了。 那可以是任何Nuget程序包，例如microsoft.aspnet.Odata 6.x或任何引用.NetStandard的程序包。
一旦进入“ true”，这里就有一个布尔设置
C：\ Program Files（x86）\ Microsoft Visual Studio \ 2017 \ ProfessionalMSBuild \ Microsoft \ Microsoft.NET.Build.Extensions \ Microsoft.NET.Build.Extensions.NETFramework.targets
看到里面（由于github注释编辑器将xml过滤掉，因此无法在此处复制文件内容）！

现在发生了什么，MSBuild认为它正在将正确的版本复制并加载到您的版本中，但是实际上，Nuget版本可能比此处的版本更新（Microsoft.NET.Build.Extensions参见上文）。 我认为接下来将发生三件事。
1）您的app.config /web.config中的程序集重定向具有错误的重定向版本，Visual Studio会警告该版本，从而显示黄色图标。 但是，VS 2017 15.3及更高版本无法真正解决问题（即使您让VS“解决”版本）。
2）.Netstandard 2.0库不是真正的net standard 2.0库，而是1.6.x库
3）编译器无法修复正确的签名，无法与netfx.force.conflicts.dll匹配，并将无效的dll复制到bin路径中

您可以将布尔开关设置为'false'，但是bin文件夹中现在不存在.NEtstandard门面，因此依赖于它们的NuGet库将失败。
总之，微软一团糟！

https://social.msdn.microsoft.com/Forums/zh-CN/51dc828b-43ca-4177-b68e-7a6a9cf81db5/ms-build-extensions-file-corrupt-my-bin-web-api-folder?forum= msbuild

此问题应在VS 15.4中修复。

@egbertn有关添加的DLL的一些背景知识和存在的一些问题，请参见https://github.com/dotnet/standard/issues/481 。 我们不知道会错误地选择DLL的“较旧”版本而不是“较新”版本的任何问题。 实际上，我们有一个“冲突解决”目标，主要根据程序集版本比较DLL并选择“最佳” DLL。 当您说未选择NuGet的较新DLL时，如何确定NuGet是“较新的”？

谢谢！

在具有Web项目的解决方案（vstudio 2017企业或社区）中，当我编译其中一个时，目标是.net 4.6.1和.net core 2，其他项目的bin文件夹已损坏并显示文件netfx.force.conflicts。 这使我浪费了很多时间。 请帮助解决该错误行为。

@techaimail对我来说解决的是将4.6.1项目迁移到新的CSProj样式。 我发现旧样式导致了我的问题。

@ Jetski5822新版本的Csproj在旧版解决方案中能正常工作吗？
在相同的情况下，我有一个DotNet（aspnet MVC4）项目。
我可以没有问题地更新项目文件吗？

因此，在尝试将内部.net核心库添加到.net 4.6项目之后，我刚遇到此问题。 绝对不知道在这种情况下该做什么，已经尝试了上述一些修复程序，但是似乎没有任何帮助。

这里有一个简要的摘要，说明正在发生的事情和需要做什么？ 在这里完全碰壁，需要解决。

您好@atrauzzi ，我和我团队一直在做的是每次我们收到错误并再次构建项目时，都删除bin文件夹。 很烦人，但错误消失了

根据@dsplaisted的说法，它将在15.4版中解决，该版本已经发布，因此请尝试升级以防万一。

更新至VS 15.4，这对我来说仍然持续存在。 解决方案共有20个项目（类库，asp.net mvc / web api，控制台应用程序，MS Test项目）-全部针对4.6.2。 调试asp.net应用程序时，出现“死亡黄屏”。 通常，它会引用一个错误来找到netfx.force.conflicts或System.Xml的正确版本

以上修复都不对我有用。 我可以调试Web应用程序的唯一方法是运行“清理”，然后使用powershell命令对obj和bin目录以及IIS Express临时文件夹进行修改。 重建并调试然后正常工作。

这是a $$的全部苦恼-它正在杀死生产力。 它仅在运行解决方案范围的nuget更新后才开始-我应该如何确定160多个软件包中的哪个是导致此问题的根本原因？

基于https://github.com/dotnet/sdk/pull/1612 ，我想此修复没有及时发布15.4。

这可能有助于忽略netfx.force.conflicts。
顺便说一句VS 2017 15.4.3和15.4.2黄色图标应该已经解决。

 <compilation debug="true" targetFramework="4.7" >
       <assemblies>
         <remove assembly="netfx.force.conflicts"/>
       </assemblies>
     </compilation>

这似乎在15.5中已修复。 我已经从CSPROJ文件中删除了RemoveNetFxForceConflicts目标，但是没有遇到错误。

感谢您的确认@Quppa。 我正在关闭此问题，因为没有任何可追踪的工作。

@UweKeim谢谢，它就像一个魅力！