Force bindingRedirect for System.Resources.Extensions

[ericstj]

System.Resources.Extensions writes a type-reference into the .resources
file it writes but RAR will never see this when considering conflicts
for bindingRedirects.

Force a bindingRedirect whenever this package is used.

Fixes #39078

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @tarekgh, @buyaa-n, @krwq
Notify danmosemsft if you want to be subscribed.

[ericstj]

I decided to generate this file since it depends on AssemblyVersion. That way we don't need to "remember" to update another place when AssemblyVersion changes.

[joperezr]

NIT: any reason why not to hardcode $(TargetFramework) to net461? I'm afraid of some future change that may change targetframeworks in the future and might make us package an extra targets file where we shouldn't. Plus, you are already hardcoding the net461 on the condition so it doesn't seem that bad to do it here too.

[ericstj]

Usually I try to minimally hardcode things. The condition hardcodes TFM once just as you would to condition items that only apply to a single TFM.

[joperezr]

Honestly this workaround feels hacky to me, but I understand this is the best way to mitigate this problem for now.

[ericstj]

Honestly this workaround feels hacky to me, but I understand this is the best way to mitigate this problem for now.

Setting a specific/matching version in resources is no better since there can always be mismatches in a project graph. I considered a facade with fixed assembly version but that violates our serviceability requirements on desktop (OOB assembly with fixed version). I feel like this is the closest representation of what should happen. The only thing I could think of that's better is if RAR would crack the resources to understand references that might exist there. It could examine this type-reference as well as other type-references that might only appear in serialized resource payloads. The cost/benefit of such a solution doesn't seem worth it.

[joperezr]

Yeah, I agree that probably the ideal solution would be for RAR to detect this automatically and suggest the binding redirects just as all the other redirects get automatically suggested without us having to manually add them, but again I think this is probably the best solution we can craft for now.

[EamonHetherton]

so this fix will come out with .NET 5 preview 7?

[ericstj]

Preview7 is already done, we can get it in Preview8. You can also just grab a nightly build off https://dnceng.visualstudio.com/public/_packaging?_a=feed&feed=dotnet5 and validate it.

[ericstj]

#39485 ports to preview8

[stonstad]

I don't believe this made it into .NET 4.8. I'm still seeing this behavior.

[tarekgh]

@stonstad which version of the System.Resources.Extensions package you are referencing in your project?

[stonstad]

@tarekgh The behavior manifests for me w/ System.Resources.Extensions 5.0.0 and 4.7.2. I am now trying 4.6 per a previous comment/suggestion.

[ericstj]

@stonstad all this change did was suggest the bindingRedirect. You still need to make sure the project has automatic bindingRedirects enabled and that your application architecture will use the config file. In the project where you're seeing this problem can you double check that it is producing a config file and that config file contains the bindingRedirect?

[stonstad]

Agreed. I can confirm auto generation of binding redirects via project properties for a Windows Forms application. I did not see automatic insertion of the redirect after initial inclusion of the package via nuget. Perhaps therein lies the bug.

…

________________________________ From: Eric StJohn <notifications@github.com> Sent: Monday, November 23, 2020 11:01:36 AM To: dotnet/runtime <runtime@noreply.github.com> Cc: Shaun Tonstad <tonstad@clarion.consulting>; Mention <mention@noreply.github.com> Subject: Re: [dotnet/runtime] Force bindingRedirect for System.Resources.Extensions (#39386) @stonstad<https://github.com/stonstad> all this change did was suggest the bindingRedirect. You still need to make sure the project has automatic bindingRedirects enabled and that your application architecture will use the config file. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#39386 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAXZBR4RTQKD3B2RBFOOMOTSRKIPBANCNFSM4O26DNAA>.

[ericstj]

@stonstad can you open a new issue with a minimal repro and we can have a look?

Here's my repro, and it has the redirects:
testSRE.zip

<dependentAssembly>
  <assemblyIdentity name="System.Resources.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>