I suggest you ...

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.

8,267 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Chuck FieldsChuck Fields shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Per BornsjöPer Bornsjö shared a merged idea: Add support for .config transformation  ·   · 
    imatioimatio shared a merged idea: Add config transformations to app.config for Unit Test projects  ·   · 
    David BuckinghamDavid Buckingham shared a merged idea: Incorporate the SlowCheetah extension directly into Visual Studio.  ·   · 
    DevSlickDevSlick shared a merged idea: Add Slow Cheetah out of the box  ·   · 
    Nick V. Nick V. shared a merged idea: Option to debug/test using the build configuration's config transform.  ·   · 
    Scott.Scott. shared a merged idea: WinForm application choose app.config for debug based on configuration  ·   · 

    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.

    Will Buik,
    Visual Studio – VS IDE Project and Build Team


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      • DaveDave commented  ·   ·  Flag as inappropriate

        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 HurdMark Hurd commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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.

      • vuvu commented  ·   ·  Flag as inappropriate

        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.

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        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, ...")

      • JerryJerry commented  ·   ·  Flag as inappropriate

        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 CourtrilleShane Courtrille commented  ·   ·  Flag as inappropriate

        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.

      • FredFred commented  ·   ·  Flag as inappropriate

        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.

      • Richard SchaeferRichard Schaefer commented  ·   ·  Flag as inappropriate

        @WillBuik - Any updates on support for SlowCheetah in VS2015? The last post to the SlowCheetah project is a "preview" update.

      • Jay TurnerJay Turner commented  ·   ·  Flag as inappropriate

        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.

      • shrishshrish commented  ·   ·  Flag as inappropriate

        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.

      • Mike-EEEMike-EEE commented  ·   ·  Flag as inappropriate

        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 SaundersJohn Saunders commented  ·   ·  Flag as inappropriate

        @random: I have never had a problem maintaining transform files. If it were painful, then nobody would want them.

      • RSRS commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        @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.

      • KevinKevin commented  ·   ·  Flag as inappropriate

        @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.

      ← Previous 1 3 4 5 24 25

      Feedback and Knowledge Base