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.
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.
.Net is failing commented
Some interesting data from the 2017 Stack Overflow survey...
C# has fallen in popularity from 45% to 34% in just 5 years.
And Xamarin is one of the most dreaded technologies in the Stack Overflow survey.
The only really successful language Microsoft ever developed was classic VB, up to its best version ever - the VB6 programming language. They have never achieved the same success since.
C Parcell commented
Just wrap this into the core code base. Cheetah/Koala or whichever, it really should be baked in at this point.
I have to agree with the last 3 comments. An extension??? Really?
I could understand if we were asking for something that does not exist on the IDE, but that is not the case. We have a feature that works fine for web.config but not for app.config. That! That is the problem.
No-one asked for an extension. If we start to use this in a new project, who tells us this extension will be maintained in 2 years, or will be working with next VS version?
We need a serious commitment, not just some code published on github and then abandoned some months later because MSFT changes its plans (again).
And btw: The item was filed on Jul 16, 2011. First MSFT reaction was at Mar 4, 2015. If you're listening, you're listening very slow.
Ian Colledge commented
Only been wait for this for about 15 years... and we get an extension
We cannot rely on everything being a third party and unsupported in 2 years extension in Visual Studio. The everything as a third party extension breaks for most corporate applications for well over half of the expected application lifespan of 7+ years.
Document retention will force applications to be kept for well over 5 years in a large company.
Relying on third party tools which will be dead or unsupported by the 2 original developers is a bad business plan on Microsoft's part.
Consider selling SQL Server to one of the largest companies and saying, 20% of your future budged for a database server will be at risk if the 2 person supported third party extension is abandoned.
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.