Azure-webjobs-sdk: "Found conflicts between different versions of the same dependent assembly" despite AutoGenerateBindingRedirects ON

[ggirard07]

I recently migrated my solution to .Net Core with .netstandard 2.0. The only project still using .Net Framework 4.6.1 is my webjob (a console app project) because the NuGet package for the WebJobs SDK supporting .Net Standard is still in preview (3.0-beta4).

My solution is working properly but I can' t get ride of this last warning:

2> C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2041,5): warning MSB3276: Found conflicts between different versions of the same dependent assembly. Please set the "AutoGenerateBindingRedirects" property to true in the project file. For more information, see http://go.microsoft.com/fwlink/?LinkId=294190.

In order to get the NuGet package management right when mixing a class library in .Net Standard with an executable still in full framework, I had to update the console app project to use PackageReference instead of packages.config, as explained here. I uninstalled every packages in the packages.config prior to switch to PackageReference and then reinstalled only the required packages. For the Microsoft.Web.WebJobs.Publish package, I used the workaround detailed in https://github.com/Azure/azure-webjobs-sdk/issues/1109 as PackageReference does not support PowerShell installation.

I found the following announcement describing a similar pattern generating this kind of warning. But it does not cover my warning as the console application is an executable and is already using AutoGenerateBindingRedirects.

Repro steps

1. Clone the repository containing the reproduction sample at https://github.com/ggirard07/bindingredirect.

2. Open the solution BindingRedirectIssue.sln.

3. Build the solution (Build > Rebuild Solution).

4. Check the build errors and warnings.

Expected behavior

No error or warning should be produced.

Actual behavior

A warning is reported about assembly version conflicts.

Known workarounds

None.

Related information

The issue starts when adding the Microsoft.Web.WebJobs.Publish package to the solution.
The warning seems to be related to a conflict about the Newtonsoft.Json.dll.
There should be no conflict in the solution as everyone is using Newtonsoft.Json in version 9.0.1.
The only reference to a different version is in the Microsoft.Web.WebJobs.Publish which use 6.0.4. it is used only during the build by the added .targets, there is no impact at runtime. This is also why the Microsoft.Web.WebJobs.Publish does not define any dependency to the Newtonsoft.Json package.

I am pretty sure this assembly, $(NuGetPackageRoot)Microsoft.Web.WebJobs.Publish\1.1.0\tools\Newtonsoft.Json.dll raises the issue because as soon as you remove the webjob-publish-settings.json file from the disk or the webjobs.targets from the console app csproj, the warning disappear (but you can no longer build the webjob...).

Versions involved:

• Microsoft.Azure.WebJobs 2.1.0
• Microsoft.Web.WebJobs.Publish 1.1.0

[mathewc]

We'll try to repro and see if there is a workaround possible or if there is an actual issue needing fixed.

[ggirard07]

Updated all my webjobs with Microsoft.Web.WebJobs.Publish version 2.0.0 which support PackageReference but issue still persist.

[dsplaisted]

I took a look at this, and here's what's happening:

• webjobs.console.targets from the Microsoft.Web.WebJobs.Publish NuGet package is importing Microsoft.WebApplication.targets
• Microsoft.WebApplication.targets is typically used by web applications, which:
  
  
  
  • Have an output type of Library
  
  
  • Use a web.config file, which is where the binding redirects go
  
  
  • Don't support automatic binding redirects (because the web.config file from the source directory is used in F5 scenarios, so the build can't update it)
  
  
• Because web applications don't support automatic binding redirect generation, Microsoft.WebApplication.targets sets AutoUnifyAssemblyReferences to false. This tells the ResolveAssemblyReference task to generate a warning message with the suggested redirects, since they won't be automatically applied.
• When AutoUnifyAssemblyReferences is false and the OutputType is Exe, MSBuild will generate the warning that AutoGenerateBindingRedirects should be set, even if it already is.

To fix this, the Microsoft.Web.WebJobs.Publish package should probably save the value of AutoUnifyAssemblyReferences before it imports Microsoft.WebApplication.targets, and restore the value afterwards.

MSBuild should also fix the issue where it can generate a warning telling you to set AutoGenerateBindingRedirects when it is already set.

To workaround this issue, you can put the following in your .csproj file after all of the .targets imports:

  <PropertyGroup>
    <AutoUnifyAssemblyReferences>true</AutoUnifyAssemblyReferences>
  </PropertyGroup>

[ggirard07]

Can this be related in any way? https://devblogs.microsoft.com/visualstudio/using-newtonsoft-json-in-a-visual-studio-extension/

[gogux]

What's the status of this? I think I'm facing this same issue with a project migrated from NetCore 2.2.100 to NetCore 3.1.201 and the proposed workaround https://github.com/Azure/azure-webjobs-sdk/issues/1598#issuecomment-468501905 doesn't work for me.

[StingyJack]

F5 scenarios

@dsplaisted - "F5" like the networking device?

Also linking this because of similar convo

[dsplaisted]

By default, F5 is the shortcut key in Visual Studio to "Start Debugging". In classic ASP.NET projects, when starting debugging, Visual Studio would not do a full build where it copied the content and web.config to an output directory. Rather it would use those files from the project directory, so there was no opportunity to inject binding redirects during the build process.

[nicholastic]

I'm also seeing this issue in my webjob. Can you get this fixed?

[dsplaisted]

@nicholastic Have you tried the workaround here?

[nicholastic]

@dsplaisted Yes, unfortunately workaround https://github.com/Azure/azure-webjobs-sdk/issues/1598#issuecomment-468501905 doesn't work for me.

[dsplaisted]

@nicholastic Can you share a binlog of the failing build (with the workaround applied)?