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.
We believe we have addressed the main issues that are top of mind regarding this UserVoice item and are closing this item as completed.
First, we have added additional support for XML files. Second, the Visual Studio team has taken ownership of SlowCheetah and will be maintaining and updating it moving forward. Lastly, SlowCheetah has been integrated with MSBuild by adding NuGet support for transformations. Projects that depend on SlowCheetah will restore NuGet packages and apply transformations after build. We need to balance adding new features to Visual Studio with performance and simplicity. The SlowCheetah extension allows users to add and preview transforms but isn’t required to execute a transform. Given a relatively low usage of these features and the flexibility in shipping we get by staying out of the Visual Studio release cycle, we believe it’s better for the Visual Studio developer community that SlowCheetah stays as an extension that is fully supported by Microsoft.
If you have additional requests for SlowCheetah or believe this resolution doesn’t meet all of your requirements, please open a new UserVoice item for that specific concern.
You can find the SlowCheetah extension here: https://marketplace.visualstudio.com/items?itemName=VisualStudioProductTeam.SlowCheetah-XMLTransforms
Please file any bugs on our GitHub page: https://github.com/Microsoft/slow-cheetah/issues
Thank you for helping improve Visual Studio!
Rune Moberg commented
The NuGet package approach works very well for me.
SlowCheetah used to be a pain in the ..., but now there is no extra files in my git repository and my build server happily pulls the NuGet package (along with countless others) and it just works.
I too am a big fan of leaving everything to msbuild, but in this case it would be better to ensure that NuGet works optimally with msbuild rather than focus on a single addon like SlowCheetah. If people here feel there is an issue with NuGet and msbuild, then address that issue first. (The default TFS build template doesn't have an issue)
TL&DR; NuGet FTW!
Daniel Smith commented
XML/Config transforms really should be core functionality built into msbuild. Why go to all the extra effort of maintaining a plugin when transforms are an almost universal feature requirement?
Jacob Viau commented
@abatishchev, in the new version of slow-cheetah the functionality of performing the transform has been moved entirely into the NuGet package. So it is now entirely msbuild based now! All you need for your build server is to perform a nuget restore. The VS extension is optional and is to assist in adding and previewing the transforms.
I believe the support should come from MSBuild, not from VS, since if build server can't reproduce this behavior then it's pointless. It's late 2017 but you still embracing the "IDE centric" approach :(
"so the nugget and vsix name has been changed..." "nugget"? Is this some sort of inside way of referring to NuGet?
Out of my more than 20 years of experience as a consultant for clients from very small to enterprise: If you are a BIG company and this is critical for your process, devs won't be allowed to use it at all because it is not officially supported by MSFT. That's how it works for most BIG companies. OSS or not, free or not, is not important, because in BIG companies licenses are negligible in comparison to the TCO of a SW development department with hundreds or even thousands of devs.
Douw Loots commented
We would all love for this feature to be baked into the VS and I'm really annoyed that MS is not making it easier for us...BUT if you are a big company and this is critical to your dev process create a fork of the GitHub repo and support it yourself. The beauty of open source.
Has Microsoft included a public statement that MS will officially support this 3rd party extension until VS 2017 is retired?
Our large company has hundreds of developers working on many large and small systems. How much risk does this and the dozens of other 3rd party extensions shipped with Visual Studio add to our company?
Third party extensions like this are 2 person projects which will very likely be unsupported of have blocking bugs in them within 3 years.
Picking the best of breed 3rd party extension to replace this one in 2.5 years and forcing an upgrade and many man-months of retesting on Visual Studio customers is not good business.
Lesson learned: Our Architecture group will only approve officially supported MS products and a very very limited set of commercial add on products. And amongst those MS supported products, only the top tier are approved. The third tier package from MS research is not allowed as they are never have MS commitment for 7+ years of support.
Document retention is 7+ years for accounting/financial and other IT systems. Being able to support/debug/build those systems in year 6+ is a business need.
Provide, as part of the, SlowCheetah nugget package a statement that it will be officially MS supported for the full lifespan of Visual Studio 2017 first.
Jakub Januszkiewicz commented
This needs to be integrated in MSBuild. An extension (or even built-in support in VS) doesn't solve the problem, as it still won't work on CI/build servers etc. Are you seriously expecting people to build release packages from within VS?
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 :)