Support for transforming web.config on F5
With SlowCheetah when you are developing a desktop project and you F5 the app.config (as well as other XML files) are transformed.
For web projects this is not the case, the transforms are only executed on package/publish. It would be better to have the same behavior for web projects as desktop projects have. When you F5 the web.config (as well as other XML files) are transformed to allow you to debug using those values.
The issue for this on the project page is at https://github.com/sayedihashimi/slow-cheetah/issues/39.
Thanks guys, this feature will take a bit of time for me to develop but based on the current votes this will be the next feature I work on.
I’m just getting back from a break so it may be a bit before I get on this. I will keep you all posted.
ivan zinov commented
Any update about this feature?
Uri Goldstein commented
There's a VS extension called FastKoala that aims to do just this:
Douw Loots commented
Thank you Jon, will have a look.
Cannot wait until this is native to VS.
Jon Davis commented
It turns out F5 transform support is already supported in web projects, or any projects, without SlowCheetah anyway, although you would not use web.config as your static base but rather, say, Web.Base.Config. Solution is here: https://gist.github.com/EdCharbeneau/9135216
Jon Davis commented
wow "thanks this will be the next feature", 2012 .. now under maintenance mode .. *sigh*
Cam Munro commented
want - want - want !!!
Douw Loots commented
With SlowCheetah being extended as the solution for XML transformation in VS2015, this would an essential addition.
Would greatly appreciate an update.
Any news on this? Really badly needed
This feature would make SlowCheetah even awesomer. Any news?
Dennis Bidstrup commented
I have added the following target to my SlowCheetah.Transforms.targets file. In my project I've a folder Tradelink (can be named whatever you want) and all .config files under this folder is transformed into a web.config. We don't have a web.config in the project. Its generate on build.
This is made for sitecore, so we have Sitecores original web.config named Sitecore.config and we copy this to web.config and make our transformations on this file.
<Target AfterTargets="CoreCompile" Name="TransformWebConfigOnBuild" DependsOnTargets="TransformAllFiles;DiscoverFilesToTransform">
<Delete Files="$(_TargetConfig)" />
<Copy SourceFiles="$(_OriginalConfig)" DestinationFiles="$(_TargetConfig)" />
<Message Text="Following files will be used to transform $(_OriginalConfig) into $(_TargetConfig): @(_FilesToTransformNotAppConfig->'%0a%09bin\%(RelativeDir)%(Filename)%(Extension)')" Importance="high" />
Condition=" '%(Filename)%(Extension)' != '$(_TargetConfig)'
and $([System.Text.RegularExpressions.Regex]::IsMatch(%(RelativeDir), '[Tt]radelink'))
and '%(Link)'=='' " />
<Message Text="AfterTarget RUN DONE" Importance="high" />
A appsettings.config example:
<add key="AllowDebug" value="true" xdt:Transform="Insert" />
We when use slowcheetah on these files, so make different results depending on our build target.
Michael Bunney commented
Some of the comments link to an article saying this can already be accomplished by naming your base config Web.template.config (or any name other than Web.config) and setting up a build-time transformation to generate Web.config from that. While this does in fact enable the debugger to use a transformed config (since at run time ASP.NET always runs against "Web.config" specifically), what it doesn't solve is that the IDE tooling has designers and extensions that modify Web.config behind the scenes -- for example, if you add a web service reference, the endpoints and bindings are added to Web.config. The tooling will not be aware that you now want it to treat "Web.template.config" as your master base config. It will update the transient Web.config that will get overwritten every time you hit F5.
Now, if the build-time transformation could generate an alternate file name and there was some way to signal that it should be used during debugging instead of Web.config, that would solve the problem. But since Web.config is looked for not only by VS and ASP.NET but also by IIS, the solution is complicated.
Another (and better, I think) solution would be for ASP.NET to support a built-in Web.Base.config, and for the IDE to recognize this as the master that was edited at design time. If other add-on tooling went through a common design-time API to edit it (rather than explicitly looking for it by file name), then all tooling would start recognizing that. Then at build time Web.config would be generated on the fly if Web.Base.config existed.
Whatever the solution, this would be a very valuable feature, because it would allow multiple developers to have their own local transforms (e.g., Web.mikeb.config) with their own settings without the risk we have today when developers modify Web.config for local development purposes but then accidentally check it in, causing the production config to be polluted. (Today the only way to prevent that is to override ALL your settings in the child configs, which would eliminate all the benefits of transformations and inheritance.)
Michael Paterson commented
This is an absolute must! I love SlowCheetah and would be ecstatic if this feature were implemented.
I am waiting for this feature too!!!
Krister Kauppi commented
Great job with SlowCheetah! The only thing that I'm missing is the support for transforming webconfig on F5. When do you think you will release that support?
Michael Chamberlain commented
Really looking forward to the implementation of this!