Support web.config style Transforms on any file in any project type
Web.config Transforms offer a great way to handle environment-specific settings. XML and other files frequently warrant similar changes when building for development (Debug), SIT, UAT, and production (Release). It is easy to create additional build configurations to support multiple environments via transforms. Unfortunately, not everything can be handled in web.config files many settings need to be changed in xml or other "config" files.
Also, this functionality is needed in other project types - most notably SharePoint 2010 projects.
The applicationInsights.config file should support .config transformations.
We want to use different logging based on the selected build profile so our different staging environments can have different type of logging.
Right now there is no easy way to use AI with "Publish" in VS.
This way, you can remove the profile part from the .config file and it will work the same way as the rest of VS .config files works.
No need to invent the wheel again.
In a continuous integration scenario you will have a Team Build set up to execute on check-in. This will kickoff a deploy to a continuous integration server and will execute unit tests against the deploy. This works fine for just running unit tests. However if you want to leverage the Unit Test framework to do some integration testing you'll run into problems with configuration for connectionstrings and webservice uri's. You'll need the ability to change the app.config for unit test depending on the environment it is testing against. Best way to do this seems to be by using the same strategy as is used for web.configs.
Support for Web.config transformations have been supported for Web Application Projects, however App.config (or Xml transformations in general) have lacked this feature. Thankfully, the SlowCheetah extension provides this functionality, but shouldn't Visual Studio support such a useful feature, natively?
Config/Xml transformations are useful for projects of all types, outside of just web projects. Windows Services are typically deployed to multiple environments (Dev, Lab, QA, Production, etc.), just like web applications. Transformations would benefit enterprise developers, just the same as web developers.
I don't understand why web config transformations come bundled within Visual Studio, but to transform fat client (Win Forms, WPF) apps, you have to download the Slow Cheetah extension. Save us all the trouble and make this an out of the box feature.
Config transforms change behavior that should be easily testable.
Without this option either the web.config must be edited or the app must be published.
Please add an easy way to use a config transform during debug and test without changing the web.config itself. If the config file is changed, then it would be easy to accidentally commit those changes to source control.
When creating WinForm projects, our projects will set the correct app.config file to be used. During Debug mode, however, the application debug code does not know which .config to use and as such reverts back to the system app.config. It would be great if the configuration manage would allow one to specify which confi file for that configuration to use (system default would be app.config if not specified)
Update 2/14/2017 – I am happy to announce that we have updated the SlowCheetah extension to work with Visual Studio 2017 and 2015. You can install the extension from the VS marketplace: https://marketplace.visualstudio.com/items?itemName=WillBuikMSFT.SlowCheetah-XMLTransforms
We are also in the process of adding support for additional project and file types. For the latest development news for the extension, check out the GitHub repo: https://github.com/sayedihashimi/slow-cheetah
Please let us know if you run into any issues by reporting them at the issue tracker on SlowCheetah’s GitHub page.
Note: if you installed the preview extension for Visual Studio 2015, please be sure to remove it before installing the new one to avoid conflicts.
Please stop marking things as progressing when they do NOT address the request.
Tudor Turcu commented
Is SlowCheetah an officially supported extension by Microsoft?
John Saunders commented
I hope everyone realizes that almost every part of Visual Studio is an extension of some kind.
Now, the fact that it doesn't get released with VS, that's an issue.
Happy to announce.. what a smuck
Wtf, they are still insisting as keeping it as an extension. We should all drop vs
Mike Jansen commented
Thankful this will be official for VS2015, VS2017. Look forward to it being integrated into VS directly some day :)
I don't know if that's good news or bad news. Was hoping this functionality would be rolled into the next version of VS.
I have no interest in using these third party tools for this very reason. They abandoned and we end up painting ourselves into a corner.
Please support this and put it into the next version of VS, so that we can do what web developers have been able to do for years.
Brett Jacobson commented
SlowCheetah on github was just updated a couple days ago, after a few years of being abandoned.
This is a must have feature for VS. For now when I publish my WebApi application (website) I get only Web.config transformed. If I move appSettings to external file it isn't transformed. SlowCheetah solves that problem, but this must be build in into VS.
Adrian Mos commented
So... SlowCheetah hasn't been updated in a while, its github page is abandoned since 2014, VS2015 has long since launched and VS2017 is close to being launched... anything?
Mark Middlemist commented
Can I just add my voice to those saying about support for visual studio 2017 config transforms. For our build processes this is a critical issue and once blocking me from recommending an early push to this version
So with VS 2017 looming where is this? Are we going to get an updated third party extension again or is this coming built in?
Please can a solution also be devised so that linked Class Libraries (e.g. If WebApp 1 and WebAppMVC and ClassLib1 all exist in the same solution), that app.settings in the class library are also carried through to each web application.
We have a large web solution that is duplicated for different clients. The only difference is the config settings to link to databases/email etc, some of which exist in the class library. Using SlowCheetah, these are currently ignored (read as null) when pulled into the web app's. Therefore currently our settings file have to exist outside the app, and be read on application_start... It seems messy when there's potential to keep this tidy, and all in one IDE!
Mark Hurd commented
I'm sure we all have changes to existing files for (local) testing too. Ones that we revert before checking-in real changes, only to redo immediately after checking-in. It is mostly app.config and web.config, but the current SlowCheetah doesn't cater for this. And I can imagine others have #defines like this.
5 years with not a solution from the Microsoft Visual Studio team. How many years will it take to get this changed?
Our commercial product team will either make the change within 1.5 years or close it out with a 'never to be done' status within that 1.5 years.
We'd lose many of the Fortune 1000 multinational customers we have if we left open customer requests and repeatedly stated 'we're considering it for a future version' to them.
Jarosław Jaskułowski commented
Please support simple automatic substitution of appSettings and connectionStrings based purely on name of variable.
The configuration file handling part of .NET should be less than a thousands of lines of code.
Pointing to a third party VS add in is OK for the short run but the third party VS add-in tool is not something a business customer's $1,000,000+ software project should not have that risk.
The basic VS tool set should be good to use and supported for 7 - 10 years for each version. A plethora of loosely supported and likely to be zombie or dead in 3 year add-ins is not a good business solution.
This is even more vital in larger project teams where we have heterogeneous systems and have to do per-developer transformations.
...speaking of, having per-developer (i.e. $username) transformations, would be just as important as having some actual support for this (and not just "this will be in VS, no we will use SlowCheetah, no this will be in VS, ...")
Agree with Fred on a plain text (key - value) pair with a path for the key. The currently complexity is a result of the path being spread out over multiple levels of nested xml tags. Json will perpetuate the nesting and the complexity.
A simple key/value dictionary will handle accessing the config file from a .net process.
This is much less complexity than a nested structure like xml or json.
Shane Courtrille commented
So serious question here. If 8,000 votes can be completely ignored why is there even a visualstudio.uservoice.com? The SlowCheetah support that was promised resulted in a single preview release and no bug fixes or support. I assume the assumption is people should now be using VSTS/TFS Release Management but if that's the case then it's time for Microsoft to say so.