Could not load file or assembly 'netfx.force.conflicts' #23174

alfeg · 2017-08-14T21:48:20Z

I've compiled project with new release of VS 2015.3. Installed .Net Core 2.0 SDK.
Project is a pretty old Asp.Net web application, where all project deps were converted to .Net Standard.

No on every page load I get

[BadImageFormatException: Cannot load a reference assembly for execution.]

[BadImageFormatException: 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.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) +225
   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

[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
   System.Web.Compilation.BuildManager.GetPreStartInitMethodsFromReferencedAssemblies() +69
   System.Web.Compilation.BuildManager.CallPreStartInitMethods(String preStartInitListPath, Boolean& isRefAssemblyLoaded) +139
   System.Web.Compilation.BuildManager.ExecutePreAppStart() +172
   System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters, PolicyLevel policyLevel, Exception appDomainCreationException) +912

[HttpException (0x80004005): 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.HttpRuntime.FirstRequestInit(HttpContext context) +534
   System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +111
   System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +718

How to resolve this?

The text was updated successfully, but these errors were encountered:

danmoseley · 2017-08-15T03:02:42Z

@ericstj do you know what 'netfx.force.conflicts' is?

oldrev · 2017-08-15T05:44:16Z

Hello, I got the same problem when I trying to run my .NET Framework ASP.NET app. Do I need to uninstall .NET Core 2.0 SDK?

danmoseley · 2017-08-15T06:54:17Z

@weshaggard

oldrev · 2017-08-15T07:41:35Z

I found a solution: delete the bin folder under your web application and rebuild them all.

chris31389 · 2017-08-15T10:55:52Z

For me, the application works when I run it in debug through Visual Studio 2017 15.3, but when I publish it to a folder that my IIS is looking at, it wasn't working.

I got it working in the end, and here were the things that I tried:

Deleting \bin and \obj folders before publishing
Deleting my folder that I publish to
Resetting IIS
Making sure that the ApplicationPoolIdentity's .NET CLR version is set to "No Managed Code"

ericstj · 2017-08-15T15:40:41Z

do you know what 'netfx.force.conflicts' is?

Its a facade that references every contract assembly that is inbox in desktop: https://github.com/dotnet/corefx/blob/master/src/netfx.force.conflict/ref/netfx.force.conflicts.csproj

It is only a ReferenceAssembly and should never make it to the application's output directory. There is no corresponding lib for this assembly since it has no typedefs and will never appear in the runtime assembly closure.

   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

Looking at that callstack it appears that Asp.NET may be doing something unusual, it looks to me like it is trying to load reference assemblies for execution. That'll fail whenever there is any assembly with the ReferenceAssemblyAttribute. @pranavkm @DamianEdwards does this look right to you?

Eilon · 2017-08-15T17:12:58Z

@pranavkm can you take a look? This might need to go to a System.Web person.

danmoseley · 2017-08-15T17:54:26Z

@pranavkm can you port to aspnet repo if appropriate?

Eilon · 2017-08-15T18:31:39Z

@danmosemsft this would be for System.Web, which isn't on GitHub, it's in TFS only. Once we see what's going on here, if we can't resolve immediately, we'll forward to the System.Web folks (different people from ASP.NET Core team).

pranavkm · 2017-08-15T20:24:06Z

I can't quite figure out how the assembly gets to the output directory. @alfeg \ @oldrev \ @chris31389 could you share your application's csproj or possibly repro steps \ application?

danmoseley · 2017-08-15T20:30:50Z

@Eilon - ah, you're quite right.

Quppa · 2017-08-15T23:17:04Z

We're seeing the same issue. We have .NET 4.7 ASP.NET projects referencing .NET Standard 1.6 projects, all using PackageReference. Deleting bin and obj and rebuilding gets rid of the warning, but I'm then greeted with a different 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)]

This may be a separate issue, but it wasn't happening with Visual Studio 15.2 and the associated tooling.

For our build server I've 'fixed' the issue by copying across the MSBuild directory from 15.2, since there seems to be no way to downgrade through the installer.

alfeg · 2017-08-16T02:43:13Z

@pranavkm my project is quite big to share. I will try to create repro later.
Actually deep cleaup of bin/obj folders help with issue, but as @Quppa write, there is a lot of broken assembly redirects for 'System.*' packages. Hopefully, second instance of VS running 15.2 version is able to build project without issues, and broken update to vs not blocked me much.

UweKeim · 2017-08-16T13:47:27Z

This issue also happens suddenly to me in a non-Core .NET 4.6.2 / 4.7 project (i.e. full .NET Framework) together with Visual Studio 2017 Community Edition.

My guess is that some NuGet package I'm using was updated and (accidentially) brings in .NET Core.

Maybe unrelated: I'm also getting tons of exclamation marks in my references list after upgrading all NuGet packages to their latest version:

When having maximum build log verbosity, I find lines like:

Primary reference "System.Security.Cryptography.X509Certificates, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". (TaskId:21)
1> Resolved file path is "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\System.Security.Cryptography.X509Certificates.dll". (TaskId:21)
1> Reference found at search path location "{RawFileName}". (TaskId:21)
1> This reference is not "CopyLocal" because at least one source item had "Private" set to "false" and no source items had "Private" set to "true". (TaskId:21)
1> The ImageRuntimeVersion for this reference is "v4.0.30319". (TaskId:21)

I have no idea why the "packages.config" reference to this "System.Security.Cryptography.X509Certificates" assembly does not actually fetch it from the NuGet-downloaded "packages\System.Security.Cryptography.X509Certificates.4.3.0\lib\net461" folder but instead looks in the MSBuild folder.

chris31389 · 2017-08-16T14:19:11Z

@UweKeim I've got the same issue. I'm having loads of The referenced component 'System.Security.Cryptography.X509Certificates' could not be found. Draycir.Approvals.WebApi and its suggesting tons of redirects.

UweKeim · 2017-08-16T14:33:15Z

@chris31389 Is there a way to get the actual error message behind a yellow exclamation mark ⚠️ in Solution Explorer?

chris31389 · 2017-08-16T15:39:55Z

@UweKeim Not to my knowledge. The messages I got were from the build output.

danmoseley · 2017-08-16T16:20:46Z

/cc @weshaggard @ericstj who may have insight.

ericstj · 2017-08-16T17:20:39Z

/cc @dsplaisted This is the built-in netstandard support for .NETFramework. For net461 and later you no longer need packages to get netstandard support, we put it in the build system.

@Quppa to fix those warnings you should apply all of the suggested binding redirects. That should resolve the YSOD. For projects with web.config this means double clicking the warnings in the error window and letting VS modify your web.config. For app.config you can enable automatic bindingRedirects and they'll be automatically written to app.config on build.

@UweKeim check your error list's warning tab. You may see the same redirect warnings that @Quppa was mentioning and applying the redirects will fix them. edit: you may be hitting dotnet/sdk#1499

Quppa · 2017-08-16T23:06:34Z

@ericstj Thanks - adding the redirects has indeed resolved the YSOD. I'm confused why we aren't getting the same error when the solution is built with 15.2.

pranavkm · 2017-08-17T00:02:30Z

@danmosemsft \ @ericstj I'm able to (inconsistently) repro the issue of the binary getting in to the bin directory with a repro app @MaximRouiller pointed to: https://github.com/alfeg/vs15_3repro. Here are the steps that I've had the most success in reproduction:

Clean the repo
Launch the sln in VS
Hit Ctrl-F5 without changing the startup project.

I'm going to loop in @HongGit to see if there's anything further that can to address from the BuildManager end.

jemiller0 · 2017-08-17T01:30:14Z

Welcome to DLL hell. This is what happens when Microsoft parrots the Java Maven world. One of the things I have always hated about Java. .NET used to be superior, but, now we are in DLL hell thanks to the advent of NuGet.

UweKeim · 2017-08-17T04:32:38Z

To me, the yellow exclamation marks remain present, no matter what I do.

To my surprise, my project otherwise seems to runs fully functional.

ericstj · 2017-08-17T04:33:58Z

@UweKeim see the linked issue I opened in the SDK repo (with workaround). I think this is what you are hitting.

UweKeim · 2017-08-17T04:50:50Z

Awesome support, @ericstj, thanks a lot. That actually did the trick! (Although I have no idea what this actually does 😕)

If the workaround will be no longer necessary in the future, will it do any harm to leave it inside my CSPROJ files?

Steps to solve

The linked solution says to add the following to the CSPROJ file:

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

Sometimes more was necessary to add to the CSPROJ file. My working CSPROJ ended up with the following added:

<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>

What also helped me was to switch the projects back from .NET 4.7 to something lower like 4.6.2.

This also requires to edit all "packages.config" files and replace "net47" with "net462" then issue the following in the Package Manager Console of VS:

Update-Package -Reinstall

And finally, I also needed to delete the /bin and /obj folder as well as the temporary ASP.NET folders in e.g. "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\temp".

ericstj · 2017-08-17T04:59:15Z

@UweKeim glad that worked for you. The thing its doing is tricking the IDE into thinking that the references that replaced your project entries actually came from the project. Hopefully we'll get the SDK to fix this bug. FWIW the same bug was present even in the project.json nuget stuff but it was less common. The workaround is mostly harmless, but it could also cause the same issue if you happened to have full-path references in the project itself. If we wanted it to be more scoped we could refine the workaround to not have that behavior.

@pranavkm I see the repro. The msbuild log doesn't show the copy happening. Indeed build of the SLN from msbuild does not repro. Build from VS does: 100% for me. I procmon'ed it and I see the copy happening from the devenv.exe process (not msbuild, though I do see the MSBuild traces so I'm certain its an out-of-proc build). I'm not getting a good callstack out of procmon so will need to debug VS to get the actual culprit. I suspect some ASP.NET component responsible for debugging the site, so would be happy if someone can step in and help from that side.

ericstj · 2017-08-17T05:07:42Z

Correction, it's not build in VS that reproduces the copy, it is debug. An updated procmon gave me a stack, here's the culprit:

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 do you know who owns mswebprj.dll? Looks like it isn't honoring Private/CopyLocal=false

HongGit · 2017-08-17T06:44:42Z

@Jinhuafei could you please take a look?

Jetski5822 · 2017-09-05T13:23:18Z

I got my library down to netstandard1.3.... and managed to remove the mvc dependency, it seems to work now.

mscrivo · 2017-09-07T19:21:52Z

I'm curious why @ericstj's workaround in https://github.com/dotnet/corefx/issues/23229#issuecomment-323119376 is not working for people. The key is to add it to all your projects in your solution(s), not just web projects. Once we did that, we have not seen the issue come back for over a week now.

andrii-litvinov · 2017-09-08T11:38:21Z

@ericstj, @mscrivo I have applied workarounds from both https://github.com/dotnet/corefx/issues/23229#issuecomment-323119376 and https://github.com/dotnet/corefx/issues/23229#issuecomment-324959465. netfx.force.conflicts is not present in /bin folders, but it complains on other reference dlls like System.Data.Common and System.Diagnostics.StackTrace with the same error:

[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

What else can I try to either remove those Reference assemblies or make those not copy to bin folders?

andrii-litvinov · 2017-09-08T12:52:03Z

I have investigated more and found that it works fine when I build web project. But when I build one of the projects that it references after build of web project I get the error from above. In particular it makes my tests fail. Any clue on what can it be? I have applied the fix to all the projects in the solution. And All are using PackageReference for NuGet.

jeremyhayes · 2017-09-08T14:28:13Z

@andrii-litvinov We had this same issue. When you rebuild an underlying project, without building the web project, it copies the "wrong" versions of the assemblies to the web bin directory. Confirmed this by diffing against a copy of "known-good" bin directory. Because the web project doesn't build, the workaround ref/lib fix target doesn't execute.

To get around this, I manually adjusted the binding redirects in the web.config for several assemblies to newVersion="4.0.0.0", the version in the GAC. I found these one by one by loading the site and updating for the assembly which caused the error. In our case it was 5 assemblies, but I expect this may differ based your project:

System.Reflection
System.Runtime
System.Runtime.Extensions
System.Runtime.InteropServices
System.Xml.ReaderWriter

Visual Studio gives warnings about those binding redirects, but I have instructed my team to ignore them for now.

andrii-litvinov · 2017-09-08T15:28:47Z

@jeremyhayes thank you for sharing your workaround! It works very well for assemblies that exist in GAC, but in my case System.Data.Common is not in GAC so this solution does not work. I am trying to understand where do those assemblies come from, because they are of smaller size (30KB comparing to 150KB when compiling web app) and possible workarounds for this.

ericstj · 2017-09-08T16:59:39Z

The assemblies are coming from "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft.NET.Build.Extensions" (vs2017) or "C:\Program Files (x86)\MSBuild\Microsoft\Microsoft.NET.Build.Extensions" (older VS's) or "C:\Program Files\dotnet\sdk\2.0.0\Microsoft\Microsoft.NET.Build.Extensions" (dotnet cli).

The assemblies under the "ref" folders are the smaller versions: they are reference assemblies that do not contain any implementation, only the metadata for our public API. The assemblies in the "lib" folder are the actual implementation assemblies.

When you rebuild an underlying project, without building the web project, it copies the "wrong" versions of the assemblies to the web bin directory. Confirmed this by diffing against a copy of "known-good" bin directory. Because the web project doesn't build, the workaround ref/lib fix target doesn't execute.

Yes, that's the bug that @BillHiebert is fixing in the web project system. It's copying the reference assemblies when it shouldn't because it doesn't notice that they set copylocal=false. Despite the fix going into the web project system we still need to make a change to the targets that are adding the reference assemblies because the project-system update won't go everywhere and we're finding more cases of other desktop build tools that try to load the reference assemblies for execution.

To get around this, I manually adjusted the binding redirects in the web.config for several assemblies to newVersion="4.0.0.0", the version in the GAC

That will break anyone who's depending on API that was added in the later versions. The ones in the GAC will be missing the API or typeforwards that were added to the assemblies.

We're working making a better fix for this, see: https://github.com/dotnet/corefx/issues/23830.

andrii-litvinov · 2017-09-08T17:50:31Z

@ericstj Thank you for a quick reply and detailed explanation. @jeremyhayes, @ijsgaus solution provided by @ericstj in https://github.com/dotnet/corefx/issues/23439#issuecomment-323855505 worked for me. I realize that it is temporary solution until better one is created by MS, but still it helps to move on with .NET Standard 2.0 on Full Framework web applications.

DaleKBurrell · 2017-09-20T02:44:31Z

I am getting a similar issue with a web application project when I try and do a release build - but strangely not when I do a debug build. I've tried the various fixes listed above with no joy. Any suggestions?
An attempt was made to load an assembly with an incorrect format: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\netfx.force.conflicts.dll
Edit: Found the cause... the release version must have been trying to generate a serialization assembly whereas the debug didn't (both set to auto) dotnet/standard#418

UweKeim · 2017-09-20T05:33:16Z

@DaleKBurrell Did you try the steps I summarized?

DaleKBurrell · 2017-09-20T06:08:46Z

Sure did - but I found the cause and added it as an edit to my original comment. Thanks for replying.

egbertn · 2017-09-24T09:23:00Z

I've investigated and lost lots of time on the issue too.
It basically starts, when MSBuild thinks you have a dependency on .NetStandard. That could be any Nuget Package, such as microsoft.aspnet.Odata 6.x or any package that references .NetStandard.
As soon as this get's into 'true', there is a boolean setting here
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\Microsoft.NET.Build.Extensions.NETFramework.targets
See inside (cannot copy the file contents here, since github comment editor filters the xml out)!

Now what happens, MSBuild 'thinks' it is copying and loading the correct version into your build, but in fact, the Nuget verion, might be -newer- than the ones from here (Microsoft.NET.Build.Extensions see above). What happens next is, I think, 3 things.

your assembly redirects in your app.config /web.config has the wrong redirect versions, for which Visual Studio WILL warn, and thus the yellow icons. However, VS 2017 15.3 and higher, cannot really solve the hell (even if you let VS 'solve' the versions).
The .Netstandard 2.0 libraries are not really net standard 2.0 libraries but 1.6.x libraries
The compiler cannot fix the correct signatures anymore and matches with netfx.force.conflicts.dll and copies that invalid dll into the bin path

You can set the boolean switch on 'false' but now the .NEtstandard facade does not exist in your bin folder, and thus, the NuGet libraries that depend on them, will fail.
In short, a total mess Microsoft!

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

dsplaisted · 2017-09-25T04:40:31Z

This issue should be fixed in VS 15.4.

@egbertn See dotnet/standard#481 for some background around the DLLs that are added and some of the issues that exist. We're not aware of any issues where an "older" version of a DLL will be incorrectly chosen over a "newer" one. In fact, we have a "Conflict Resolution" target which compares the DLLs and chooses the "best" one, primarily based on assembly version. When you say that a newer DLL from NuGet isn't being chosen, how are you determining that the NuGet one is "newer"?

Thanks!

techaimail · 2017-10-09T16:14:12Z

In a solution (vstudio 2017 enterprise or community) with web projects target .net 4.6.1 and .net core 2 when I compile one of them the others get its bin folders corrupted and appears the file netfx.force.conflicts. This is causing me a lot of time lost. Please help with fix that wrong behavior.

Jetski5822 · 2017-10-09T16:19:40Z

@techaimail what fixed it for me is to migrate the 4.6.1 project to the new CSProj style. I found the old style was causing me the issue.

reinaldocoelho · 2017-10-09T16:23:09Z

@Jetski5822 The new version of Csproj works fine in legacy Solutions?
I have a DotNet (aspnet MVC4) project in the same situation.
Can I update project file without problems?

atrauzzi · 2017-10-10T15:30:29Z

So I've just encountered this issue after trying to add an internal .net core library to a .net 4.6 project. Have absolutely zero idea what to do in this case, have tried some of the fixes above, but nothing seems to be getting me through.

Is there a concise summary of what's happening and what needs to be done here? Completely hit a wall here and need to resolve.

reyronald · 2017-10-10T15:37:10Z

Hello @atrauzzi , what my team and I have been doing all this time is just deleting the bin folder every time we get the error and building the projects again. It's annoying, but the error goes away

According to @dsplaisted it was going to be solved in version 15.4, which is already out so try upating just in case.

geekcubed · 2017-10-10T17:09:44Z

Updated to VS 15.4 and this is still persisting for me. Solution has a total of 20 projects (class libraries, asp.net mvc / web api, console apps, MS Test projects) - all targeting 4.6.2. Yellow Screen of Death appears when debugging asp.net applications. Typically it references a faliure to find the correct version of netfx.force.conflicts or System.Xml

None of the above fixes have worked for me. The only way I can get the web apps to debug is to run a Clean, then have a powershell command that nukes obj and bin directories along with the IIS Express temp folder. Rebuilding and debugging then usually works.

This is a total pain in the a$$ - it's killing productivity. It only started after running a solution wide nuget update - how am I supposed to figure out which one of the 160+ packages is the root cause for this?

Quppa · 2017-10-11T00:36:25Z

Based on dotnet/sdk#1612, I guess this fix didn't make it in time for 15.4.

egbertn · 2017-11-08T21:23:44Z

This might help ignoring netfx.force.conflicts.
b.t.w. on VS 2017 15.4.3 and 15.4.2 the yellow icons should have been solved.

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

Quppa · 2017-12-06T23:40:46Z

This does seem to be fixed in 15.5. I've removed the RemoveNetFxForceConflicts target from my CSPROJ files and haven't encountered the error.

weshaggard · 2018-01-18T00:17:00Z

Thanks for the confirmation @Quppa. I'm closing this issue as there isn't any work left to track.

in10se · 2018-07-11T15:31:55Z

@UweKeim Thanks, it worked like a charm!

Eilon assigned pranavkm Aug 15, 2017

pranavkm removed their assignment Aug 17, 2017

ericstj assigned dsplaisted and unassigned dsplaisted Sep 7, 2017

weshaggard closed this as completed Jan 18, 2018

msftgits transferred this issue from dotnet/corefx Jan 31, 2020

msftgits added this to the 2.1.0 milestone Jan 31, 2020

ghost locked as resolved and limited conversation to collaborators Dec 21, 2020

Could not load file or assembly 'netfx.force.conflicts' #23174

Could not load file or assembly 'netfx.force.conflicts' #23174

Comments

alfeg commented Aug 14, 2017

danmoseley commented Aug 15, 2017

oldrev commented Aug 15, 2017

danmoseley commented Aug 15, 2017

oldrev commented Aug 15, 2017

chris31389 commented Aug 15, 2017 • edited

ericstj commented Aug 15, 2017

Eilon commented Aug 15, 2017

danmoseley commented Aug 15, 2017

Eilon commented Aug 15, 2017

pranavkm commented Aug 15, 2017

danmoseley commented Aug 15, 2017

Quppa commented Aug 15, 2017 • edited

alfeg commented Aug 16, 2017

UweKeim commented Aug 16, 2017 • edited

chris31389 commented Aug 16, 2017

UweKeim commented Aug 16, 2017 • edited

chris31389 commented Aug 16, 2017

danmoseley commented Aug 16, 2017

ericstj commented Aug 16, 2017 • edited

Quppa commented Aug 16, 2017

pranavkm commented Aug 17, 2017

jemiller0 commented Aug 17, 2017

UweKeim commented Aug 17, 2017

ericstj commented Aug 17, 2017

UweKeim commented Aug 17, 2017 • edited

Steps to solve

ericstj commented Aug 17, 2017 • edited

ericstj commented Aug 17, 2017

HongGit commented Aug 17, 2017

Jetski5822 commented Sep 5, 2017

mscrivo commented Sep 7, 2017 • edited

andrii-litvinov commented Sep 8, 2017 • edited

andrii-litvinov commented Sep 8, 2017

jeremyhayes commented Sep 8, 2017

andrii-litvinov commented Sep 8, 2017

ericstj commented Sep 8, 2017

andrii-litvinov commented Sep 8, 2017

DaleKBurrell commented Sep 20, 2017 • edited

UweKeim commented Sep 20, 2017

DaleKBurrell commented Sep 20, 2017

egbertn commented Sep 24, 2017 • edited

dsplaisted commented Sep 25, 2017

techaimail commented Oct 9, 2017

Jetski5822 commented Oct 9, 2017

reinaldocoelho commented Oct 9, 2017

atrauzzi commented Oct 10, 2017 • edited

reyronald commented Oct 10, 2017

geekcubed commented Oct 10, 2017

Quppa commented Oct 11, 2017

egbertn commented Nov 8, 2017 • edited

Quppa commented Dec 6, 2017

weshaggard commented Jan 18, 2018

in10se commented Jul 11, 2018

chris31389 commented Aug 15, 2017 •

edited

Quppa commented Aug 15, 2017 •

edited

UweKeim commented Aug 16, 2017 •

edited

UweKeim commented Aug 16, 2017 •

edited

ericstj commented Aug 16, 2017 •

edited

UweKeim commented Aug 17, 2017 •

edited

ericstj commented Aug 17, 2017 •

edited

mscrivo commented Sep 7, 2017 •

edited

andrii-litvinov commented Sep 8, 2017 •

edited

DaleKBurrell commented Sep 20, 2017 •

edited

egbertn commented Sep 24, 2017 •

edited

atrauzzi commented Oct 10, 2017 •

edited

egbertn commented Nov 8, 2017 •

edited