Propose to improve binding redirects genenration

[gillg]

Hello,

The current solution with a target to replace web.config with the build config file is not so bad, but implies to version kind of "statics" binding redirects. Moreover, I guess they will remains even if your dependancy doesn't need a binding redirect anymore, or if you uninstall it...

I suggest something like that in SystemWeb targets :

  <Target Name="AfterBuild">
    <XmlPeek XmlInputPath="$(TargetDir)\$(AssemblyName).dll.config"
             Query="/configuration/runtime">
      <Output TaskParameter="Result" ItemName="GeneratedBindings" />
    </XmlPeek>
    <WriteLinesToFile
        File="$(TargetDir)\Web.bindings.config"
        Overwrite="true"
        Lines="&lt;?xml version=&quot;1.0&quot;?&gt;&lt;configuration&gt;;@(GeneratedBindings);&lt;/configuration&gt;" />
  </Target>

And in your personal Web.config you remove ALL the binding redirects and you replace them by :

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  [...]
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <linkedConfiguration href="file:./bin/Web.bindings.config"/>
  </assemblyBinding>
</configuration>

What do you think about it ?

[gillg]

P.S: I edited my previous description, in Web.config, and in case of linkedConfiguration it seems that the assemblyBinding node has to be outside <runtime>

[slang25]

In my testing (a very long time ago) I found that the path would be ignored if it's relative, and would only work if it's an absolute path.
Have you managed to get it working?

[CZEMacLeod]

@gillg Looks like an interesting technique. I think there are a couple of issues though.
If it requires absolute paths (as @slang25 states) this would not work well.
When doing the initial compilation, the web.bindings.config file would not exist. This might result in errors due to a bad web.config file, and require you to compile again. In the case of a build server this wouldn't work well.

I think there might be some argument to keep the web.bindings.config file next to the web.config file, and keep it in source control. This would allow you to see if the actual config was changed, or if it was just assembly updates.

Can you confirm which versions of dotnet framework support this method - I couldn't find when it had been added in the MS docs.

The only other issue is that it requires manual intervention to add in the linkedConfiguration snippet. This could be done during the build process if it doesn't exist, I suppose, but then you are already updating two files, and they update every time.

The current target UpdateConfigWithBindingRedirects checks the hashes of the (potentially) modified config file including any new redirects, and only overwrites the original web.config if it differs. I think this is more efficient in general.
You are more than welcome to add your own target to your project file that behaves the way you describe, and not turn on OverwriteAppConfigWithBindingRedirects. If it works well, and doesn't suffer any of the issues previously described, feel free to post a link to an example repo, and we can look at adding it in; probably behind a different flag so you can choose which methodology to use.

To my mind though, the OverwriteAppConfigWithBindingRedirects feature basically makes up for the fact that you cannot double click the error message in the errors log like you can with a 'traditional' project, and leaves you with basically the same management tasks as you would have anyway. That way you don't have to learn a new method and any quirks that arise from it.

[slang25]

At my work we have a pretty gross convention of razor generating our web.config files, which has caused us all kinds of pain, but did allow for me to leverage this little known feature to get automatic binding redirects working well for us.

I remember trying for quite some time to solve this with relative paths and it never working, it's an undocumented behaviour and a real shame.

[gillg]

At my work we have a pretty gross convention of razor generating our web.config files, which has caused us all kinds of pain, but did allow for me to leverage this little known feature to get automatic binding redirects working well for us. I remember trying for quite some time to solve this with relative paths and it never working, it's an undocumented behaviour and a real shame.

Indeed the relative path seems fails silently... I didn't realize it ! I definitely don't understand how this feature can be usable without relative path !
Nevermind, I love your trick ! But I guess the code part is not directly in the Web.config ? It's part of your application?
There is no bad effect to include the whole dll config which contains the whole web.config (including linkedconfiguration) + bindings ?

[slang25]

Yeah, what I'm showing in that screenshot is useless to anyone else 😆 We happen to generate our web.config files as we deploy them, I cannot recommend anyone doing that.

But I do remember trying to solve this for the longest time, linkedConfiguration feature is essentially useless in it's current form.

[gillg]

Oh !!!
Investigating deeper, the relative path is relative to bin folder !
So this is definitely working !

    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
	    <linkedConfiguration href="file://Web.bindings.config"/>
    </assemblyBinding>

So following @CZEMacLeod recomendations to version the file alongside Web.config si probably working with ../Web.bindings.config
But I'm not super fan to version this one and not other generated binding for library projects.

I just tested, and I don't have any warnings if I remove Web.binding.config before the build !
My guess is :

• CSC make the build
• AfterBuild target create the file
• aspnet_compiler uses web.config and resolve the binding file.

EDIT: My bad @CZEMacLeod I think I just missed the warning ^^ So we always have the problem, but it seems not completely different than the current approach where we have to run the build two times no ?

Am I wrong ?

[gillg]

To finish answering @CZEMacLeod XmlPeek seems exists since a long time : https://github.com/dotnet/msbuild/commits/main/src/Tasks/XmlPeek.cs like https://github.com/dotnet/msbuild/commits/main/src/Tasks/FileIO/WriteLinesToFile.cs
(they was already existing in 2015, during the first public git commit)

[slang25]

Ooooh, that's huge! I'll do some exploring on my side and see if we can remove some of the hacks we have.

[gillg]

To be discussed, but we could admit to add <NoWarn>MSB3276</NoWarn> by default to avoid errors and trust the automatic binding generation.

[slang25]

🤔 I haven't got it to work yet, the file I want to link is in the bin folder, but it's not taking effect. I'll keep testing

[gillg]

🤔 Except if it was another joke it should work. The compiler was happy... I will check again when I can.

[CZEMacLeod]

@gillg The current approach requires running the build 2 times after a library/package update. (Or really just once to do the binding update). That code can then build on a build server without warnings and only needs building once, locally or remotely. Also, if you checkout the code, or perform a clean it compiles immediately without multiple compile steps. Your approach seems to always result in warnings that need supressing.

I wasn't referring to when the MSBuild tasks were added - It would be relatively trivial to add code and custom tasks if it couldn't be handled by MSBuild directly - I was referring to the assemblyBinding / linkedConfiguration elements in app/web.config.

You mention not checking in the auto-binding redirect files of libraries. I think the difference here is that a web application project is not really a library, but is the actual execution point for the project, even if it is a DLL not an EXE and is launched 'inside' of IIS.

There are a few other issues, with not having the config file as part of the project, when it comes to publishing etc.
Also, I believe that VS requires the correct bindings in place for when it edits razor pages, otherwise it cannot handle intellisense etc. (This might be an issue if you checkout or clean the code and the bindings config is deleted).

Right now, I'm not getting the vibe that this is any more robust, or user friendly, than the current approach, although it may work better for specific use cases.

I'll still consider a PR for a fully featured solution, but it should be completely generic, and require the absolute least amount of work from an end user to use. Having to go back to a project and remember how something worked, or get someone else up to speed with it, is always a pain point. Just now you can set the property and basically forget about it - you will get the warnings (and message telling you it is fixed and to recompile) if you do an update in the future and not have to worry.

I kind of feel right now that any logic and/or custom tasks required for this, would be better bundled up as a separate design-time nuget package - maybe something like MSBuild.SDK.SystemWeb.LinkedBindings. You could then install it if you wanted the binding redirects handled this way, or just use the SDK 'bare' and enable OverwriteAppConfigWithBindingRedirects if you want to do it that way. If there is anything specific that needs hooking or adjusting in the SDK to work this way, I'd be happy to oblige, and/or accept a PR for that.

[gillg]

Thanks you a lot for all your details !
I will sleep on that and think if something matching all the needs could be done.

[CZEMacLeod]

I have just released a new package for razor class libraries.

As part of that package I

1. Set the default of OverwriteAppConfigWithBindingRedirects to true instead of false. I'm not sure if I should also update the main package - I'm not sure if anyone is using this without the option at the moment.
2. Added the XmlPeek/XmlPoke version to support updating any web.config files that are not in the root - e.g. with custom settings like in the Views folder.

Things I found out:

1. The built-in mechanism that generates the binding redirects does some odd stuff with having multiple assemblyBinding elements.
2. When using XmlPoke, it seems to mess up line endings (I think specifically in multi-line comments). It may also affect the whitespace for end tags in some cases.

This leads to -

1. A warning about inconsistent line endings when opening the file in the editor.
2. If you then check in the changes - you get a lot of other changes showing in git other than the bindings that have changed.

I am considering whether to move this functionality into its own package (as previously described) so that it could be shared between the two SDKs, and whether to write a custom task to do it in .NET rather than rely on the native MS Build tasks, and their foibles.

@gillg @slang25 If you have any further thoughts on this - especially as compared to using linkedConfiguration elements - I'd be interested to hear from you.