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,769 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 →

    516 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...
      • Douw LootsDouw Loots commented  ·   ·  Flag as inappropriate

        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.

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        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 JanuszkiewiczJakub Januszkiewicz commented  ·   ·  Flag as inappropriate

        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 ParcellC Parcell commented  ·   ·  Flag as inappropriate

        Just wrap this into the core code base. Cheetah/Koala or whichever, it really should be baked in at this point.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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.

      • John SaundersJohn Saunders commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Wtf, they are still insisting as keeping it as an extension. We should all drop vs

      • Mike JansenMike Jansen commented  ·   ·  Flag as inappropriate

        Thankful this will be official for VS2015, VS2017. Look forward to it being integrated into VS directly some day :)

      • MikeMike commented  ·   ·  Flag as inappropriate

        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.

      • MisiuMisiu commented  ·   ·  Flag as inappropriate

        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 MosAdrian Mos commented  ·   ·  Flag as inappropriate

        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 MiddlemistMark Middlemist commented  ·   ·  Flag as inappropriate

        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

      • Anonymous commented  ·   ·  Flag as inappropriate

        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?

      ← Previous 1 3 4 5 25 26

      Feedback and Knowledge Base