<AutoGenerateBindingRedirects> doesn't work for class libraries

[tmat]

The property is ignored unless the containing project is an .exe.

Extensible frameworks/apps that load plugins might support loading configuration for each plugin, including binding redirects, from a .dll.config file next to the plugin .dll. For example, a unit-testing framework such as xunit. See also proposal #1309, which might also make use of this feature.

I propose the restriction on project type is removed and binding redirects are generated for any project that sets AutoGenerateBindingRedirects to true.

[tmat]

//cc @ericstj

[nguerrera]

cc @piotrpMSFT @krwq @dsplaisted There is a similar requirement for the CLI team

[tmat]

Also there need to be a way how to specify the target framework for which the redirects need to be generated. Is there is a way to do so for a class library?

[kdowswell]

this issue is blocking me from using Microsoft.AspNetCore.TestHost in a .net 4.6.1 test project targeting asp.net core .net 4.6.1 in VS 2017. Manually adding the binding redirect attributes to my test proj doesn't help. :(

[bradphelan]

The magic sauce seems to be to add

<PropertyGroup>
  <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
  <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>

but I don't understand why there are two props with basically the same meaning. I found this here

and then my libraries started generating binding redirects.

[bradphelan]

But now it stopped working again.... totally inconsistent behavior :(

[bradphelan]

Oh yes it does. I've figured it out. ;) When set the below on a library project

<PropertyGroup>
  <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
  <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>

(1) If there are no binding conflicts then the *.config file is not generated.
(2) If there are binding conflicts then the *.config file is generated.

[JoseFMP]

Over here I tried to activate both
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
but no effect.

Also, no effect either in library or exe file. Like... redirects not created at all.

[bradphelan]

If you don't need the binding redirects then it will not generate them. At least that is what I have found.

[JoseFMP]

I need them. That's why my software does not start.

[danrozenberg]

I am also suffering from this. I get the MSB3276 warning, but adding

<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>

Does nothing...

I am using the new MSBuild-based tooling (that means, using <Project Sdk="Microsoft.NET.Sdk.Web">

[tmat]

This should work:

  <Target Name="ForceGenerationOfBindingRedirects"
          AfterTargets="ResolveAssemblyReferences"
          BeforeTargets="GenerateBindingRedirects"
          Condition="'$(AutoGenerateBindingRedirects)' == 'true'">
    <PropertyGroup>
      <!-- Needs to be set in a target because it has to be set after the initial evaluation in the common targets -->
      <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
    </PropertyGroup>
  </Target>

[danrozenberg]

tmat, it does work, thank you!
Is there any way to see which binding redirections were made?

[tmat]

Yes, there should be a .dll.config file generated to the output directory.

[nguerrera]

Fixing this (not requiring any specific output type) is required to unblock microsoft/vstest#792

[danrozenberg]

tmat, although I said it worked earlier, I was mistaken, I had changed the command line directory to another project and didn't realize I was building something that didn't have MSB3276 to begin with. At this point, I am still getting that warning, even when using the Target solution. Sorry about that...

[danrozenberg]

To be honest, I think what I am experiencing is an issue with the warning showing up even when the binding redirection is being done...so the warning trigger is being too sensitive...

I do get the .dll.config file with the correct redirections, either using the Target technique, or any other technique that sets the AutoGenerateBindingRedirects to be turned on.

I might have to find a more appropriate issue to discuss this... thanks for the help so far, though!

[JoseFMP]

@tmat Your solution worked for me... thank you so much! So now the redirects are created. Surprising to see how many... I envision it's going to be a hard time to work with .NET Standard libraries. Based on the fallacy of interoperability between frameworks and platforms....

[dasMulli]

It shouldn't need to be set in a target since the common targets only set it to true, never to false (am I missing something?).
At least it worked for a few users on SO:
https://stackoverflow.com/questions/43995432/could-not-load-file-or-assembly-microsoft-extensions-dependencyinjection-abstrac/43996389
https://stackoverflow.com/questions/43955266/interface-in-netstandard-1-1-library-does-not-have-implementation-in-net-4-61/43955719

[JoseFMP]

I am aware it worked for others. But for me the only thing that worked was setting it with the target solution @tmat proposed. The rest did not generate any binding at all.

[ericstj]

To understand why static properties might be different than the target you can look at the evaluated project by using msbuild /pp. I suspect that the order of import and/or the contents of the targets themselves differs between the projects.

[ericstj]

/cc @bradwilson

[Curdie]

I sure wish I had found this last month. I must have spent 60 hours working around it. How is this still a thing four years later? Must be trickier to fix than it seems.

[MS-Manikandan]

Hi , i am using .net framework sdk style test project which has 3 project references 2- .net standards , 1- .net framework which is also converted to sdk style . I have added these in the unit test project but still the compiler throws the below warnings

1. Warning MSB3277 Found conflicts between different versions of "Microsoft.CodeAnalysis" that could not be resolved.

2. Warning NU1702 ProjectReference '.csproj' was resolved using '.NETFramework,Version=v4.8' instead of the project target framework '.NETStandard,Version=v2.0'. This project may not be fully compatible with your project. ObjectModel[.net standard 2.0 project] C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets 1717

3. Warning MSB3836 The explicit binding redirect on "Newtonsoft.Json, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" conflicts with an autogenerated binding redirect. Consider removing it from the application configuration file or disabling autogenerated binding redirects. The build will replace it with: "". .UnitTests C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets 2321

Unit testproject

reference projects

[a-einstein]

Thanks tmat, it helped me to get things going again after a lot frustration. For me it helped to get rid of version errors about packages.

I was working on a WCF-service on .net 4.8. What I did was remove packages and redirects from web.config, to start with a clean slate. Thinking I could regenerate necessary redirects when re-adding packages. That did not happen.

Now the target method gave me the redirects in a dll.config. I think they did not have effect there, but by copying them to web.config they did. Now I had a working situation, even without having to re-add packages, with some recreated redirects (apparently dependencies), but with different version numbers. Apparently there had been a lot to sort out.

This may also have been working in an API service, but then directly through the dll.config. I am not sure, but I suddenly lost warnings about redirects while building.

[EgoPingvina]

This should work:

  <Target Name="ForceGenerationOfBindingRedirects"
          AfterTargets="ResolveAssemblyReferences"
          BeforeTargets="GenerateBindingRedirects"
          Condition="'$(AutoGenerateBindingRedirects)' == 'true'">
    <PropertyGroup>
      <!-- Needs to be set in a target because it has to be set after the initial evaluation in the common targets -->
      <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
    </PropertyGroup>
  </Target>

but what to do if it doesn't help?
ASP application on .Net 5.0
Its really append redirects to .dll.config but I still see System.TypeInitializationException: The type initializer for 'Google.Apis.Json.NewtonsoftJsonSerializer' threw an exception. System.IO.FileLoadException: Could not load file or assembly 'Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'. The located assembly's manifest definition does not match the assembly reference. (0x80131040)'

[rainersigwald]

@EgoPingvina Binding redirects as a concept do not apply to .NET 5.0 (and didn't apply to .NET Core). .NET 5.0 will load according to its own rules. It sounds like in your case the copy of Newtonsoft.Json.dll that is available at runtime is not version 12.0.0.0 or higher.

[EgoPingvina]

@rainersigwald but I use Newtonsoft.Json.dll v13.0.1 in project and see the dll in after-build folder. You want to say that this parameters doesn't work on .Net 5.0 at all?

[rainersigwald]

You want to say that this parameters doesn't work on .Net 5.0 at all?

Correct: .exe.config entries for bindingRedirect and other related properties are completely ignored on .NET 5.0.

You might find the techniques described in this doc on assembly-load debugging helpful for your situation.

[EgoPingvina]

completely ignored on .NET 5.0.

sounds sad. and is it real to fix this problem on .Net 5?

[ericstj]

sounds sad

It's actually not. Most of the time you never need to think about assembly binding rules on .NETCore. The runtime will typically allow a newer version to win. The exceptions are if you're trying to downgrade a dependency or implement a plugin host. There's a of assumptions being tacked onto an existing issue here. Perhaps you can open a new issue with a simple repro? Might be a better way for folks to have a look at what you are facing and make a suggestion to fix it (or identify a unique bug if that's the case).