This package enables you to transform your app.config or any other XML file based on the build configuration. It also adds additional tooling to help you create XML transforms.. Written by: Sayed Ibrahim Hashimi, Chuck England and Bill Hiebert
This extension has saved my countless hours setting up automated builds and continuous deployments. This is a must have if you need to do configuration file transforms during your build and deployment process.
Terrific work -- the only problem with web.config can be solved with a little trickery (http://stackoverflow.com/questions/16225304/using-slowcheetah-config-transforms-on-web-config-in-a-3-5-web-forms-app).
Very useful. I like that it looks at the Publish Profiles, although be cautious when you rename a Profile, it does not rename the previously generated transform files. But you can always regenerate and delete the old.
Simply does not work with ClickOnce. I have not found any information that shows how to make XML transformations work with ClickOnce. You can run the transform preview and it looks correct, but the .config.deploy file generated by ClickOnce is the original, untransformed config file. Very frustrating and completely unusable in my situation.
A real must if you wish to deploy to different machine with different configuration settings stored inside some other [filename].config. Still wonder why Microsoft don't have this functionality out of the box.
I spent an afternoon trying to get this going for a team project. After a fair while thrashing with the already-mentioned "The SlowCheetah.Xdt.TransformXml" task could not be loaded from the assembly" problem, I eventually solved it by deleting the %localappdata%\Microsoft\MsBuild\Slowcheetah folder and it semed to resolve itself on my local machine and I was allowed to build and run stuff. I then deployed this to my colleagues who didn't have the plugin, under the impression that the NuGet package would make everything alright. No joy, regardless of what I tried. I'm now having to see if I can hand-roll a solution for changing config settings for people. Gets 2 stars because I like the idea and it kind of worked on my machine.
Hi, I'd like to exclude certain transformation files from source control because they contain sensitive info. I noticed I have the option to exlude the app.config file, but not the "subfiles" created by this extension. How can I make sure the sensitive info doesn't make it's way to source control?
Hello, I have a hard time to set up app.config, app.debug.config and app.release.config in my console application.
If in the local app.config there is “<add key="ServiceID" value="R2" />”. And in the server it should be
<add key="ServiceID" value="R1" />.
I can’t use “R1” in mylocal machine to debug, otherwise an exception is thrown out.
I did add <appSettings xdt:Transform="Replace"> in the app.release.config.
Then the value is “R1” in app.release.config and it is “R2” in app.debug.config. Is it right?
1) What is the value in app.config? "R1" or "R2"? I need a direct answer.
2) When I check in the code app.config, What is the value in app.config?
A little explaination is appreciated.
I have just installed and am using Slow-Cheetah. I am using it to transform my Log.config which is used by Log4Net. It is modifying the original config file, and not just the config file in the output directory. This means that if if have an 'Insert' transform and build 3 times, I will get the XML element inserted 3 times into the original file.
Can you confirm this bug?
I've reproduced this with a bare bones project. It is an Empty Web Application and I am running the transforms on Log.config. You can see that if you build the app multiple times, the original Log.config file has the XML inserted every time.
The I am using VS2010 Ultimate SP1.
Thanks for sharing the project. When I extract this and run the app the source config file is not changed at all. I'm not sure what's going on here. What OS are you running? I have win 8 here.
One thing that might help here is to share a build log with me. For the project you shared, can you try the following. In VS go to Tools->Options->Projects and Solutions->Build and Run, set MSBuild output verbosity to Diagnostic. Kick off a build which causes the file to get modified. Copy and paste the build log from the output window. If you could email that to me at firstname.lastname@example.org I can compare it to that of my machine and see what the difference is here.
I think this is the same error I've mentioned above. It's attempting to write over the original source file: Could not write Destination file: Access to the path '***originalfilepath***' is denied. Windows 7 Professional, VS 2010.
I have a team member that is experiencing the issue while I am not being impacted. We both have pretty identical desktop images, however our VS installs are different (he has Pro 2010 while I have both Ult 2010 and Prem 2012). I'll get diagnostic traces from both his and my version of the same project and send them to you as well.
My colleague and I have downloaded the repro project and have verified that his environment is affected while mine is not. Both he and I ran builds with diagnostic output enabled and the one main thing I see is that in my log (which is transforming correctly) I see the following:
OriginalItemSpec = C:\Users\user.x.name\Downloads\SlowCheetah\SlowCheetah\SlowCheetah\bin\**\*.*
The above lines are *not* present in my colleague's build log. I'll email you both logs in their entirety for you to investigate.
What I found is that the Targets file may be incorrect. I'm running Visual Studio 2010 Premium. Here's what I was getting:
6>Task "SlowCheetah.Xdt.TransformXml" (TaskId:286)
6> Transfroming source file: X:\**********************\Data\DataModelClient\ServerURLConfig.xml (TaskId:286)
6> Applying Transform File: ServerURLConfig.Debug.xml (TaskId:286)
6> Output File: bin\Debug\ServerURLConfig.xml (TaskId:286)
6>X:\**********************\packages\SlowCheetah.2.5.5\tools\SlowCheetah.Transforms.targets(101,5): error : Could not write Destination file: Access to the path 'X:\**********************\Data\DataModelClient\ServerURLConfig.xml' is denied.
6>Done executing task "SlowCheetah.Xdt.TransformXml" -- FAILED. (TaskId:286)
When I change the Destination attribute on the task as follows, it works properly:
Two things that I should have made note of: the transform was failing before because the XML file was read-only. The second is that referencing projects are copying the non-transformed XML into the bin directories. That may be an unrelated item, but is a result of the fact that the XML file is being transformed in the referenced projects bin folder instead of the XML source location.
Just installed SlowCheetah, love the concept. But I've run into a bit of a problem: after adding a transform, the files app.Release.config & app.Debug.config appear in the directory, but not in the solution list within visual studio (2010). That is, while app.config is there, no "+" is next to it, nor are the other two files shown anywhere. Any clue what I'm doing wrong? Or is this a known bug? I've tried creating a blank visual basic project, added in an app.config file, transformed it, and got the same result.
I have a web.config and some transformations for it. whenever i try to preview a transformation (great feature!) i see lots of changes. This is mainly because SlowCheetah strips additional spaces from my original config file, and thus showing lots changes. see this example image: http://screencast.com/t/mZPbrpVRudh
here you even see spaces are stripped out from comment. Is this by design?
Just right click on Add Transform on some XML file. It will add the NuGet package automatically if its not installed. Then make sure to enable package restore. With package restore even if the user doesn't have SlowCheetah installed the files will be transformed. SlowCheeth (the VS extension) just provides the VS command to add transform/preview. The rest of the functionality is in the NuGet package. That's one of the great benefits of this update.
This is a strange one. I had a client install the slow cheetah extension and then build the project. The web config in the project was transformed to whichever build config was selected. This behavior is not reproducible on my machine or my colleagues'. This is a Visual Studio 2010 Professional w/ SP1. One thing I did notice was he didn't have nuget package manager installed yet. We're troubleshooting this tomorrow and I'm proposing to remove both extensions then add Nuget and last add slowcheetah (through nuget).
Have you seen this behavior reported before and if so, was there a set of steps to prevent it?
I have very similar behavior and can reproduce it with VS 2010 and SlowCheetah 2.5.5. I create a new ConsoleApplication, add a file called testFile.config, right click and select Add Transform. The Debug and Release Versions are added and I make slight alterations ending up with:
If I build with Debug configuration selected, the testFile.config file is modified to be:
Everytime I re-build, I get two additional <myDebugTag>s added. Similar behavior with Release, it just adds two <myReleaseTag>s. I have a colleague with version 2.5.1 of SlowCheetah and it does not exhibit this behavior.
We are working on VSTO Addin for Excel on VS 2010 and using this tool for transformation. When we build it is transforming, but not when we publish. And this will then be integrated for TFS builds as well.
It seems to work for WPF and Windows publish.
Are we missing anything here? Any pointers would be helpful.
I've never tried this scenario before, so am not surprised that it doesn't work. If you'd like this feature please create a new entry at http://slowcheetah.uservoice.com/. Once it gets enough votes I will consider implementing the feature.
I stumbled upon SlowCheetah last week. Very cool extension. I see it has been recently upgraded to be NuGet dependent. This causes a couple problems for my group:
1. We have made the decisions that developers should not use NuGet.
2. Our TFS build server is not Internet facing, so downloading from NuGet as part of the build is not possible.
If I could find a link to the older version of SlowCheetah, we could use that. Even that though is not ideal, as we would be stuck on an old version, not being able to take advantage of new features.
Any other groups in the same situation as myself and any thoughts from the developer on this? Thanks.
Thanks for the comments. Are your concerns that it uses NuGet or that it connects to the internet? If it is related to connecting to the internet take this into consideration.
When SlowCheetah is installed if you have a custom local repo defined in VS it will pull packages from that location instead of from nuget.org. You could also put a feature request in at http://slowcheetah.uservoice.com/ for SlowCheetah to drop the NuGet package on install and then reference it from that location instead of going to nuget.org. This should be pretty straight forward and I should be able to implement it.
If the concern is simply the fact that it uses NuGet, then take the following points into consideration.
1. NuGet is used by many projects types by default in VS 2012.
2. Microsoft will be investing more in NuGet (i.e. its not going away anytime soon, and it will be used more and more)
3. Benefits to using the NuGet package:
3.1 When SlowCheethah is installed by one developer, all devs will get the transform behavior even if they didn't install the package.
3.2 When SlowCheetah is executed from an automated build package restore facilitates transforming the XML files.
With those points the benefits out weigh the negatives.
If you'd like to use a version which has the previous behavior the best thing to do is to fork the repo at https://github.com/sayedihashimi/slow-cheetah and build whatever version you desire. I won't be supporting that though, you'd be on your own.
I hope you consider these points.
Sayed Ibrahim Hashimi
We plan to use SlowCheetah to transform config files in the studio and on build server TeamCity.
Transformation: Web.config + Web.$(Configuration).config + Web.$(PublishProfile).config
We would like to use this scheme to other configuration files, such as App.config and NLog.config and etc.
Its at the project level because NuGet package restore is a project level concept. With that said if you have multiple projects in a solution which each have SlowCheetah you only need to invoke the packageRestore.proj for one project. All the files for the solution go into the same folder. So there is no benefit of calling packageRestore.proj multiple times for the same solution.