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.

7,568 votes
Vote
Sign in
Check!
(thinking…)
Reset
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  ·   · 
    under review  ·  Visual Studio TeamAdminVisual Studio Team (Product Team, Microsoft) responded  · 

    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

    484 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • 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:
        http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/9347001-improve-reboot-visual-studio-project-system

        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.

      • Random JoeRandom Joe 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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Isn't this perpetuating the artifact per environment anti-pattern? 'only build your binaries once' as recompiling introduces inefficiency into your deployment pipeline

      • Tudor TurcuTudor Turcu commented  ·   ·  Flag as inappropriate

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

      • PiotrPiotr commented  ·   ·  Flag as inappropriate

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

      • Anonymous commented  ·   ·  Flag as inappropriate

        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

      • John SaundersJohn Saunders commented  ·   ·  Flag as inappropriate

        @anonymous, why do want Microsoft to waste resources on a problem which already has a solution? Only with the withdrawal of support did it become necessary for Microsoft to spend resources.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Will Buik I would like an answer to my last question, why has it taken the author to stop supporting slow cheetah for you to change your mind and support this most requested feature? Why is it not built in like it is for web.config?

      • Anonymous commented  ·   ·  Flag as inappropriate

        While this is welcome news, it just blows my mind that this was not even part of your plans for 2015!? Why not, how could you ignore your users for so many years?

        Every developer I know relies on slow cheetah and you guys at MS must surely use it too? It should have been an integral part of the msbuild and visual studio project environment from the start.

        Please stop adding themes and new icons and deliver real beneficial tools.

      • Tudor TurcuTudor Turcu commented  ·   ·  Flag as inappropriate

        A similar config transform should exist and should be built-in in the new JSON-based configuration system that will replaced the current XML config files in .NET.
        MSBuild, csproj and XML .configs will become obsolete in the future, but the core problem solevd by Slow Cheetah remains.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Slow Cheetah is used quite expensively in our organization. Please support on future VS releases

      ← Previous 1 3 4 5 24 25

      Feedback and Knowledge Base