Add `GeneratedBindingRedirectsAction` option that fully refreshes all binding redirects

[julealgon]

We are currently using GeneratedBindingRedirectsAction=Overwrite, which appears to only add or modify existing binding redirects, but it doesn't touch any potentially stale ones.

Because of this behavior, we got to a point where we started seeing binding errors after package upgrades, as some of the previous redirects in the web.config file became stale and then started to conflict with transitive dependencies again.

To fix this issue, we manually deleted the entire binding redirects section from each of our 7 projects that rely on this SDK, and let it regenerate all of the bindings again from scratch after a new rebuild. This refresh worked fine.

What worries me the most is that we had already done such a refresh at one point right after making the SDK conversion, so these stale/incorrect entries were filled completely automatically by many package updates since then.

I'd like to avoid having to ever do this process again. It is super error prone, and it is complicated to do as it requires deep understanding of redirects which most modern developers are not aware of.

I'd like to propose a new option for the GeneratedBindingRedirectsAction that instead of just updating existing redirects or add missing ones, completely replaces the entire <runtime> section with a freshly generated one. We'd then use this option for every single one of our projects so that package management always results in the leanest possible list of redirects and we don't ever run into the issues we ran into again.

[CZEMacLeod]

I have looked at this in the past - there are some problems - some of the ASP.NET compilation (MVC Views, WebForms etc.) occur outside if the roslyn build process, and the required bindings don't get detected during a normal build.
Also, the way the bindings work, you effectively have to build twice to get the desired output. Sometimes you can't even build the project at all if you remove all the bindings.
This makes it more difficult to do this on every build, but it might be possible to add it to the Clean target to remove all binding redirects (and merge a list of known good, required bindings as needed).
This would allow you to force a clean-up with Rebuild, and then build again to refresh things.

[CZEMacLeod]

You can try adding this to your project file to enable the above scenario.
I haven't fully tested this yet, and it might need to have some additional stuff to clean up the web.config for Views in MVC too.

  <PropertyGroup>
    <CleanBindings>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
          <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
          <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
        </dependentAssembly>
        <dependentAssembly>
          <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
          <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
        </dependentAssembly>
      </assemblyBinding>
    </CleanBindings>
    <AppConfigNamespace>
      <Namespace Prefix="ab" Uri="urn:schemas-microsoft-com:asm.v1" />
    </AppConfigNamespace>
  </PropertyGroup>

  <Target Name="CleanBindings" AfterTargets="Clean">
    <XmlPoke XmlInputPath="$(AppConfig)"
           Value="$(CleanBindings)"
           Query="/configuration/runtime"
           Namespaces="$(AppConfigNamespace)" />
  </Target>

We could certainly consider having a property to enable this with EnableCleanBindings or similar and add it in - although we might need to think about what is actually included in the CleanBindings property.

I feel it would need more testing to ensure it is robust before including it in the SDK itself though.

[julealgon]

Thanks @CZEMacLeod , I'll consider your suggestion of automating it, although it would be super nice if this was something built into the SDK so we didn't have to maintain that added complexity on our side.

I feel it would need more testing to ensure it is robust before including it in the SDK itself though.

Totally fair.