-
-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Propose to improve binding redirects genenration #34
Comments
P.S: I edited my previous description, in Web.config, and in case of |
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. |
@gillg Looks like an interesting technique. I think there are a couple of issues though. I think there might be some argument to keep the 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 The current target To my mind though, the |
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 ! |
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. |
Oh !!! <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 I just tested, and I don't have any warnings if I remove Web.binding.config before the build !
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 ? |
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 |
Ooooh, that's huge! I'll do some exploring on my side and see if we can remove some of the hacks we have. |
To be discussed, but we could admit to add |
🤔 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 |
🤔 Except if it was another joke it should work. The compiler was happy... I will check again when I can. |
@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 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. 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 |
Thanks you a lot for all your details ! |
I have just released a new package for razor class libraries. As part of that package I
Things I found out:
This leads to -
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 |
I think there might be a way to let MSBuild write the bindingredirects directly to the web.config file and do it early enough in the build process to not need to run the build twice. It does still mean that for a source-controled code base, that bindingredirects are likely to be merged/checked in, but that is happening now for legacy web projects. What if you were to do something like the following: Sdk.props
Sdk.targets
|
@leusbj Very interesting. I had not tried to force the output config file to overwrite the web.config file before. This looks like a very promising approach. |
@CZEMacLeod Yes, I have tried it. I have previously created (and never shared) a similarly purposed SDK project type, But I recently came across this one, and would rather contribute here, than maintain one myself. Tapping into the The other benefit of placing the target that early in the build process is that
Let me know if you would like me to try creating a pull request incorporating that change |
@leusbj I'm more than happy to take a PR from you including this feature. <ItemGroup>
<None Include="web.BindingRedirects.config" Condition="EXISTS('web.BindingRedirects.config')" />
</ItemGroup> |
With the inclusion of the new binding redirects options, I'm going to close this issue. |
I've noticed while updating to MSBuild.SDK.SystemWeb v4.0.79, the conditional include of Web.BindingRedirects.config, which lead me to this issue. @CZEMacLeod I couldn't find the use of Web.BindingRedirects.config documented on the wiki, and I was wondering whether this new feature would allow one to have auto-generated binding redirects @ compile time (with overwrite of Web.BindingRedirects.config)? |
@stevenvolckaert The documentation is a little behind I'm afraid - but the messages generated should direct you to the solution. |
That's clear @CZEMacLeod, thank you for explaining. |
@gillg I tried to use this setup while converting my project to SDK-style but couldn't make it work. Can you or @CZEMacLeod elaborate on how this is supposed to work? First, there is no such I was hoping that this approach would keep the binding redirects "hidden" for the most part and always auto-generate them on build in a completely transparent manner (similar to how it works with other modern projects where there is no need to have a bindingRedirects section in the Perhaps I'm missing something here, but I've also not seen this method documented in the Wiki. For now, I've included the <OverwriteAppConfigWithBindingRedirects>true</OverwriteAppConfigWithBindingRedirects> Flag in my project but I'd ideally want to not have to have the binding redirects all explicit in my |
@julealgon In this case, the web.config file is part of the head project and is used from the root of the application, rather than being converted to xxx.exe.config beside the compiled file in the bin folder. As such it is not possible to 'hide' the bindings from the source code, as it won't compile if the bindings file does not exist (if you use the linked config mechanism). <GeneratedBindingRedirectsAction>Overwrite</GeneratedBindingRedirectsAction> as per the templates. |
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 :
And in your personal Web.config you remove ALL the binding redirects and you replace them by :
What do you think about it ?
The text was updated successfully, but these errors were encountered: