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 7/30/2015 – A preview release of SlowCheetah for Visual Studio 2015 is available on the VS Gallery – https://visualstudiogallery.msdn.microsoft.com/05bb50e3-c971-4613-9379-acae2cfe6f9e. Please let us know on our GitHub if you run into any issues – https://github.com/sayedihashimi/slow-cheetah. We will try to fix them as soon as possible. The preview only supports VS 2015, but we will be expanding that soon.
Hello. This suggestion has gained a great deal of momentum so we would like to share our plans to address configuration driven XML transforms in Visual Studio. We understand that this is potentially blocking many teams and projects from moving forward to Visual Studio 2015. While we will not be implementing this functionality in Visual Studio 2015 itself, we do plan to update the SlowCheetah extension to fully support Visual Studio 2015. Our long term plan, however, is to integrate this functionality into a future version of Visual Studio.
We will update the community when SlowCheetah has been updated with support for Visual Studio 2015.
Visual Studio – VS IDE Project and Build Team
Mountjoy Nissalke commented
Mountjoy Nissalke commented
Our escorts in Ahmedabad are complex and knowledgeable school going youthful tight and provocative young ladies not at all like free old prostitutes from call girls in Ahmedabad city.
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.
Macro variables in config files would fix this and be easier than the other proposed solutions. Simple text replacement macro variables from a single project master macro configuration file.
This is a single pass macro variable method with no support for nested macro variables or no support for anything more than "VARIABLE_A_PATH","TEXT FOR VARIABLE A" in the file.
VARIABLE_A_PATH would be a multilevel path to allow for scoping - e.g., "DEVICES/SCANNERS/SCANNER_1"
Json and other proposed schemes are mildly less difficult than .net serialized to xml config files yet will ultimately lead to the same problems as today in ~5 years.
Give us simple comma delimited KEY <-> Value pairs in a normal text file one per line with escape characters for embedded returns, quotes, commas, line feeds anywhere in the line.
Lowest common denominator will get 90+% of the scenarios and adding gold plating for the remaining 10% is not worth it.
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.
We spent 1 man month on a recent project writing a tool to modify multiple configuration files for other parts of our large solution. It should be easier than using a clumsy special purpose .NET searialized to XML BCL.
Sayed Ibrahim Hashimi commented
I'm now getting questions on supporting Visual Studio "15", see https://slowcheetah.uservoice.com/forums/185106-general/suggestions/14939145-visual-studio-15-preview-2-support. Based on the comment above from Will Buik, I was hoping that this functionality would be baked into the product by now.
Richard Schaefer commented
@WillBuik - Any updates on support for SlowCheetah in VS2015? The last post to the SlowCheetah project is a "preview" update.
Rudi Larno (Avantida) commented
@Visual Studio Team => better just integrate this KISS solution: https://visualstudiogallery.msdn.microsoft.com/579d3a78-3bdd-497c-bc21-aa6e6abbc859
Automatically transform app.config or any other config during build process. Once the transformation is set, it will run on other build machines without the extension.
Simple, effective solution imho.
Jay Turner commented
This feature is very important to me as I have as WEB site instead of a WEB app and there is no support for transforms built in. I use SlowCheetah to address my needs.
It is such a wonderful thing , you have the ability to transform the key, values very easily and efficiently.
Please continue this, we all want it.
Wow I cannot believe I haven't seen this vote until now. 7,000+ votes! FOUR YEARS! How does that happen?! That is like going to college and getting a degree in developer relations fail. There really needs to be more accountability in UserVoice in how long a vote has been open, along with the last time that the administrator has engaged their audience (some weighting around the vote count wouldn't hurt, either).
With that said, it's good to see the admin responding since late July. Even though this is a terrible cadence ("Agile" has sprints every two weeks?), it is still better than other votes that I have seen here and on UWP's board (OVER one year?! Simply unconscionable!)
Anyways, reading over the comments and I have to relate to some of the angst other developers are feeling/expressing here. It really seems that .NET is way overdue for a reboot in its project and configuration. There is a movement to make .JSON files the new configuration but that is based in a web technology and not a MSFT-based system. XDTs are a creative approach to configuring an application, but at the end of the day, the web/app.config system is based on XML and the tooling support is TERRIBLE, especially when you compare it to the mature and available designer tools in Xaml (a MSFT invention).
In addition to XDT support for current/legacy projects, MSFT should really also be spending cycles towards revisiting and innovating its project/configuration system altogether, and in a way that doesn't subjugate itself to external web technologies (thereby decreasing its IP portfolio and ultimately its market value). Food for thought here:
After spending four years towards NOT doing something towards completing a vote, maybe the answer (also?) involves something a little bigger/ambitious. :P Thank you for any consideration/support.
(Seriously. Four years. That IS a college degree, folks.)
John Saunders commented
@random: I have never had a problem maintaining transform files. If it were painful, then nobody would want them.
No Transforms! They are rather painful to manage I think.
I'd prefer to have multiple for example Web.Config files instead.
Actually for Azure deployment ConnectionStrings can be exchanged in the Publishing dialog. However the same thing does not apply for example to <appSettings>.
Keeping environments apart (configuration wise) could be way better. Selecting a "config profile" on publish might do the trick.
Can we get an update on this? Such as an ETA?
@Kevin, Release Management do this manually or is it automated? If it's automated then the developer settings can just be held for the dev environment, Let devs override specific settings so it doesn't get in the way and you don't need a transform anymore.
@Anonymous, I am actually using config file transforms even though I am only building once.
My base config file is set up with the default settings for a developer workstation. I have a single "Release" transform that will replace things like connection strings with tokens, which Release Management will then replace with the appropriate value per environment.
Isn't this perpetuating the artifact per environment anti-pattern? 'only build your binaries once' as recompiling introduces inefficiency into your deployment pipeline
Tudor Turcu commented
@Anonymous, the explanation is quite simple: for .NET vNext a future Visual Studio versions, Microsoft intends to replace the XML-based configuration system (and replace MSBuild too), and to use JSON config files for new projects in the future. Sure, they will be supported in the future, but not developed further.
This, combined with the fact that the SlowCheetah author was promoted to some management position in Microsoft, explains why config transforms are not built-in in VS2015.
Fernando Silva commented
Anonymous said it all
@Anonymous: well I guess John Saunders really does not get it, what is sad is that in the .NET community I meet a lot of people like him that try to feed others with this attitude (mostly coming from MS I suppose) which is only causing harm and promoting wrong mindset among developers..
John is that a serious question?
Well, if it honestly is then there are so many answers, but I will provide the most obvious which is that most developers are still not aware of this plugin and have been forced to come up with other ways to solve this issue. Custom build scripts, batch files, batch files, team city, I have seen a plethora of other solutions (ranging from clever to absolutely hideous).
Your frankly glib and short cited response 'well there is a solution out there already so why bother' is symptomatic of MS attitude (I would guess you probably work for them) and has led to millions of wasted hours in writing boiler plate deployment code, CI issues and fixing of release bugs thanks to config errors and a multitude of non standard approaches to a day to day issue.
The fact that someone at ms implemented this for web.config and then didn't bother or wasn't allowed to expand it to XML or just app.config showed a massive lack of understanding of what professional developers really need.
Instead they were changing icons to grey (despite negative feedback) and captialising fonts? And you sit there telling me this would be a waste of time? You are not a professional developer.
There are so many other answers to your question but yea they are all pretty obvious