I suggest you ...

Support .NET Builds without requiring Visual Studio on the server

To build certain PCL libraries and libraries for Windows 8 RT requires having Visual Studio on the server.

Nick Berardi writes about a workaround that allows running a build server without VS, but it's really just a workaround for functionality that should be easy.

Not to mention there's probably licensing considerations we're just ignoring by doing that.


Please make it easy (and legal) to build .NET projects on a server without requiring a Visual Studio installation (or license) on that server.

4,482 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Phil Haack shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

Thank you for your feedback, and your overwhelming support for this feature.

To support the creation of more lightweight build servers, we now have made available Visual Studio 2017 Build Tools (https://www.visualstudio.com/downloads/#build-tools-for-visual-studio-2017-rc). This release allows you to build native and managed MSBuild-based projects without requiring the Visual Studio IDE. By default (that is without selecting any workload options) the Build Tools provides support for managed projects. You can also optionally install the Visual C++ compilers and libraries, MFC, ATL, and C++/CLI support.

While Visual Studio 2017 has not yet RTM’d, we’re marking this User Voice suggestion as “Completed”, and we will continue to update the Visual Studio 2017 Build Tools as we provide updates to Visual Studio 2017.

If you have additional capabilities that you would like to see included with the Visual Studio Build Tools, please create a new User Voice entry so that we can more easily track your feedback.

Thank you once again for your support for this request!
—The Visual Studio Team


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • irperez commented  ·   ·  Flag as inappropriate

    I mentioned this to MSFT 5 years ago, and their official response was "As Designed"...

  • Graham Bunce commented  ·   ·  Flag as inappropriate

    @martin. No, the build environment should be as stripped bare as possible to make sure there is nothing on it, in the gac, etc that mean it can build in one environment but not another. "works on my machine" pseudo-certification should be avoided, and can be with a clean room build server, so +1 from me...

  • Søren Nielsen commented  ·   ·  Flag as inappropriate

    And when you allow this, also allow for a way for Clickonce applications to change assembly name and productname, to allow for side by side installation of Test, CI and Production versions.

  • Sten Frostholm commented  ·   ·  Flag as inappropriate

    I would very much like to see a special build server MSI installer - which shoud install only the necessary stuff required to build .NET Projects made from Visual Studio (without VS itself). Not only Windows 8 builds requires workarounds if VS is not installed

    Here is a few examples we had to deal with at GN ReSound:

    1) Put Microsoft unittesting dll's in NuGet packages - normally located in the GAC here:

    2) Add another Visual Studio Web Publishing dll to source control (C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll).

    Above is just examples, I'm sure many other task, build and test stuff is missing if VS is not installed on a build server.

    3 votes from me

  • Martin Hinshelwood commented  ·   ·  Flag as inappropriate

    Should I point out that there are no licencing considerations with this. You are free to install VS Ultimate on all of your build servers if your organisation owns even a single Ultimate licence. Your build server should reflect your development environment and not your production one... there is no compelling reason to invest in not requiring VS on the build server.

  • Kat Lim Ruiz commented  ·   ·  Flag as inappropriate

    I agree, although the request should be stated differently.
    The request should be: make Visual Studio, as an application, lighter, more portable and more self-contained (everything under one folder like Eclipse, or all the others).
    And this would automatically drive the separation of interests between the tools, the IDE, and so on.
    Additionally, when we install several VS versions it's ****!. All the DLLs, different folders, csproj associations, etc.

  • MotoWilliams commented  ·   ·  Flag as inappropriate

    Also doing file system web publishing would be a must for a build server.

    I've gotten it working with the following steps:
    - Installing BuildTools_Full.exe
    - NDP451-KB2861696-x86-x64-DevPack.exe
    - Copying C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\ from a VS Machine
    - Copying C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications\ from a VS Machine

    But this should be a simple installer to go from a clean OS install to working build server. For the sake of the children of planet earth don't make this part of TFS.

  • Immo Landwerth [MSFT] commented  ·   ·  Flag as inappropriate

    I completely agree. It's more than just PCLs, though. It's effectively all SDKs and 3rd party tools that extend the build process, such as Windows Installer XML (WIX). I'm not trying to say "this is no my problem" (in fact it's very much in my yard) but I think we need a more generalized approach, akin to package management.

  • matthewdeanmartin commented  ·   ·  Flag as inappropriate

    Better yet, could this be a part of the RTM TFS. In certain large organizations you can't event get power tools or service packs on a TFS server, forget about Visual Studio.

2 Next →

Feedback and Knowledge Base