We currently use TFS 2010 and have numerous build definitions for our various version of our software. We want to use VS2012 for our next version(still using TFS 2010) so is it possible to have both versions of VS on a build controller and will the build process know which version of VS to use or will we need one build controller for VS2010 and one for VS2012? Also I have custom build templates will that present any issues? Then what happens when we upgrade to TFS 2012? will we be able to run automated builds using both VS2010 and VS2012??
In general - yes. Actually Visual Studio doesn't build anything. It's the underlying MSBuild engine that handles the build tasks.
Furthermore, you can setup a build machine without Visual Studio at all, provided that your project don't hold direct references to Visual Studio references paths (e.g. C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ReferenceAssemblies). If there are such references you can copy them to your 3rd party\lib directory in the source control and have the projects refer to that directory as file references.
Other notes:
But Visual Studio will hardly be your biggest hindrance. It's
multi-targeting .NET that will require some extra caffeine :)
The build templates will work as long as you satisfy their custom
references (GAC can used for that matter)
A build controller can be registered with one server at a time
Use a build server for each target framework\VS version
Related
I am trying to replicate my development environment into my build server in order to debug an error that occurs only in the build server, The same solution is compiled with msbuild that is located in C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe in both machines.
In the development machine, the solution is getting compiled successfully while in the build server it fails.
Reading the outputs from msbuild I noticed that in both machines the build is done with different versions of Microsoft build engine
dev machine: 14.0.25420.1
build server:14.0.23107.0
In order to rule out that this error relates to the version
I tried to pass the msbuild from the dev machine to the build server and ran it there which output the build server version.
How can the same msbuild yield different version on a different machine?
How can I update the build engine?
How can the same msbuild yield different version on a different machine?
According to the official blog MSBuild is now part of Visual Studio!:
Starting with Visual Studio 2013, the 2013 version of MSBuild will
ship as a part of Visual Studio instead of the .NET Framework.
So at this moment, MSBuild.exe have the same version of Visual Studio 2015, you can check the version of Visual Studio 2015:
So update the version of Visual Studio on the build server to have the same version MSBuild.exe.
Update for comment:
Is it possible to update msbuild without installing visual studio?
The answer is yes, you can download the Microsoft Build Tools 2015, install it to update msbuild.exe without installing Visual Studio.
Please refer to the document MSBuild is now part of Visual Studio! for details:
The New Microsoft® Build Tools Package
MSBuild is now a component of Visual Studio and will ship with all
SKUs of Visual Studio, including Team Build so if you use Visual
Studio all of your build needs should be covered. We understand that
there are a great number of reasons that you may want to use MSBuild
and other build tools without needing to install Visual Studio so we
are making the tools available as a new standalone package called
Microsoft® Build Tools. The package includes MSBuild and the VB/C#
compilers. The new package can be acquired here on the MSDN Download
Center.
This standalone package is great for build servers requiring fine
grain control of their build process. With this new approach to
evolving MSBuild, you have more control over build behavior and are
not impacted by .NET Framework versions.
Hope this helps.
Can we use MSBuild without Visual Studio 2012?
Currently, we have a build server where we are compiling and creating deployment copy of one of our projects, it has Visual Studio Professional Edition installed. We are setting up a new build server now. Do we really need Visual Studio 2012 on the new build server?
If yes, then how? I googled it but I couldn't find an answer.
We have spent a lot of time trying to get our Build Servers to work without Visual Studio.
We do not use TFS for builds and therefore I am not sure the license exemption above applies to us. Also not having Visual Studio installed helps you really understand how your software is building and get references correct.
We have seen many examples of solutions with projects that contains references for the same piece of software with some in nuget packages shipped with the solution and others that are pointing to locations in the "program files" path which are not present on machines without Visual Studio installed. Once you attempt to build software without VS installed you can really see how "self-contained" your applications are.
Before I start listing the things you typically need to install, let me just point out that MS Build is now no longer considered part of the .NET framework but is shipped with Visual Studio but can also be installed separately. See this blog post for more: http://blogs.msdn.com/b/visualstudio/archive/2013/07/24/msbuild-is-now-part-of-visual-studio.aspx
The following software needs to be installed for most builds, there may be others for example if you are creating portable class libraries.
Microsoft Build Tools 2013
Web Deploy 3.5 (for packaging applications)
Microsoft .NET Framework 4.5.1 Developer Pack
Microsoft .NET Framework 4.5.2 Developer Pack
Windows Software Development Kit (SDK) for Windows 8 (You can use the SDK to build applications that target these operating systems: Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008)
The following directories need to be copied:
Reference Assemblies (need to be copied from a machine running Visual Studio from/to directory C:\Program Files (x86)\Reference Assemblies)
Public Assemblies (need to be copied from a machine running Visual Studio from/to directory C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\PublicAssemblies
We also use Wix and therefore we install the following:
WIX Toolset 3.8
I have a similar set for testing however that was not part of the question so I will leave that off!
Hope this helps someone.
Update: 3rd March 2017
Microsoft recently responded to a long standing user voice request "Support .NET Builds without requiring Visual Studio on the server" for the requirement for Visual Studio to be installed on a build server to be removed.
From the description on the download page "These Build Tools allow you to build native and managed MSBuild-based applications without requiring the Visual Studio IDE." Not tested yet but after RTM I will look at this and provide a further update here.
There is a blog post that promises these build tools install all pre-requisites and can be used to build MS Build based applications.
No, you don't need Visual Studio on your build box. If I recall correctly, msbuild is installed as part of the .NET framework - it certainly used to be.
Depending on what you're building, you may find that there are some things which are easier to get working if you do install Visual Studio though - things like portable class library profiles. While there are usually non-VS installers available, I've found it simpler to install an Express edition of Visual Studio just to get the bundled build targets.
Remember: The easiest way to build your visual studio solutions is to install Visual Studio on the build server. Even Visual Studio Express is often enough.
That said, you can make it work without it. But it it sometimes a lot of work to figure out. You'll need to install the right Windows / .NET Platform SDK. You can install multiple of these SDKs side by side. Now, when you depend, for example, on ASP.NET MVC 5 or Entity Framework 6, you might need to install further SDKs to get your application to compile. The downloads for these all assume that you also have Visual Studio installed, but many of their payloads can also be installed separately. It can become quite a hassle.
Personally I've grown tired of trying to figure out which parts of which installers enable what. But that is also driven by the fact that Microsoft allows you to install Visual Studio on a build server (TFS) with the same license as your development machine as long as you are an MSDN subscriber. Check the Visual Studio License Whitepaper for more details.
Using Visual Studio on the Build Server
If you have one or more licensed users of Visual Studio Ultimate with MSDN, Visual Studio Premium with MSDN, or Visual
Studio Professional with MSDN, then you may also install the Visual Studio software as part of Team Foundation Server
2013 Build Services. This way, you do not need to purchase a Visual Studio license to cover the running of Visual Studio on
the build server for each person whose actions initiate a build.
If you, like me, would prefer this to change in the future, I suggest you make sure you're heard by submitting your request or voting for an existing one over at the Visual Studio User Voice.
Here's just a quick take on this.
Your build machine should decouple development tools as much as is possible. With that said, and as already stated by others here, MSBuild can be run independently of Visual Studio, and it should!
If your build requires Visual Studio to run then there is a very good chance that you have a solution or project architecture problem that ought to be resolved.
Visual Studio doesn't need to be installed. MSBuild is part of the .net SDK.
Other .net dependencies will need to be installed though, if you are using them. MSTest, or anything that is part of Team foundation will require Visual Studio installed.
I believe you only need MSBuild ( that is part of the .NET framework you're targeting ) .
Make sure you install the proper .NET distribution
the following is a good place for build servers it have the developer tooling.
The .NET Framework 4.5.1 Developer Pack installs the multi-targeting pack for .NET Framework 4.5.1. Developers can build applications targeting the .NET Framework 4.5.1 using either Visual Studio 2012 or third party IDEs. You need to download the web installer instead of this package if you intend to redistribute .NET Framework 4.5.1.
http://www.microsoft.com/en-us/download/details.aspx?id=40772
Best of luck.
C++ :
There is a "Build Tools" that contains MSBuild, Visual studio is not required.
From the official doc :
These tools allow you to build C++ libraries and applications
targeting Windows desktop. They are the same tools that you find in
Visual Studio 2015 in a scriptable standalone installer. Now you only
need to download the tools you need to build C++ projects.
Managed :
The same applied : Build Tool Managed
Background
I am open sourcing a few old Visual Studio applications I created a while back. I have created new solutions using my new VS2012 environment for them and have gotten the projects set up as git repositories. I got everything working fine in Visual Studio 2012 with no changes to the source code, all I needed to do was make sure I was linking the proper libraries in the new project configurations.
I would like to configure these projects as to have maximum compatibility for others downloading the project from Github. On this machine I have VS2010 installed alongside the latest VS2012 version. After I got everything working right for both of the projects in VS2012, I tried to open them up in VS2010.
When I tried to build I got a single error:
Specified platform toolset (v110) is not installed or invalid.
Please make sure that a supported PlatformToolset value is selected.
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets 518
What I Tried
So I opened up the properties for the project, went to Configuration Options --> General and the Platform Toolset was indeed set to Visual Studio 2012 (v110). This input is a drop down box and the v110 value is not listed, instead I get two choices:
v100
v90
These correspond to VS2010 and VS2008 respectively. If I change the value to v100 and rebuild I get no errors and my program runs just fine in my Visual Studio 2010 environment.
When I open the project back up in Visual Studio 2012, if tells me that I have an old project file and asks if I want to upgrade, I say yes and it upgrades. I rebuild and run to make sure everything is still working. When I open the configuration options in VS2012 the Platform Toolset is set back to `Visual Studio 2012 (v110) but clicking the drop down input there are several more choices listed:
Visual Studio 2012 (v110)
v110_wp80
Visual Studio 2012 - Windows XP (v110_xp)
Visual Studio 2010 (v100)
Visual Studio 2008 (v90)
‹inherit from parent or project defaults›
My Questions
This has led me to several questions. I am going to pose them all. It would be nice to get as much information as I can, but a good answer to just one of them would probably solve my problem.
If I'm not using features specific to newer versions of Visual Studio, is it possible to set up a solution which can be opened and run without modification in as many versions as possible (ie. 2008, 2010, or 2012)? If so, how?
If I set the Platform Toolset to v90 (VS2008) from within Visual Studio 2012, and it's able to build and run, does this mean that it will build and run for users with VS2012, VS2010, and VS2008?
What exactly does the <inherit for parent or project defaults> option do? What would the project defaults be set up as? Can this be used to tell Visual Studio to try to using whichever installed Platform Toolset will work.
Are there any other options besides Platform Toolset in Visual Studio that I can set to increase compatibility with others' development environments?
This is a somewhat tricky situation. One of the underlying problems here is that VS2010 and VS2012 use MSBuild to build C++ projects, but VS2008 farmed it out to VCBuild instead. You can see this by comparing the project files. VS2010/VS2012 use .vcxproj, while VS2008 uses .vcproj.
If I'm not using features specific to newer versions of Visual Studio,
is it possible to set up a solution which can be opened and run
without modification in as many versions as possible (ie. 2008, 2010,
or 2012)? If so, how?
For maximum compatibility, you want to target the lowest common denominator (i.e. vc90 in this case). Note that when you do the upgrade, the solution file and project files get upgraded to the latest version, which may break compatibility with older versions of Visual Studio.
If I set the Platform Toolset to v90 (VS2008) from within Visual
Studio 2012, and it's able to build and run, does this mean that it
will build and run for users with VS2012, VS2010, and VS2008?
Not really, due to the .vcxproj / .vcproj conflict stated above.
For example, I currently have a set of .vcxproj files and a solution designed for VS2010. I use VS2012 as my IDE, so when I open the VS2010 solution in VS2012, I choose to NOT upgrade it and simply open it as is. VS2012 and beyond should be backwards compatible back to VS2010 as far as project files go.
For maximum compatibility in development environments, my recommendation would be use VS2010's solution as the baseline, targeting v100. Developers can use any version newer than that and it should all work together gracefully.
Does anyone know the components that need to be installed in order to make the Package Target available via MSBuild.
It's possible to Package using MSBuild on a machine with Visual Studio installed, but not on a build server with only the .NET 4 SDK and Web Deploy 2.0 installed, which results in the following error:
msbuild "Package" does not exist in the project.
It partly comes down to the following missing files on the server:
c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\*.*
This can of course be resolved by copying the contents of the MSBuild VisualStudio folder to the equivalent directory on the build server, but this is not a manageable solution for server configuration.
All the answers I've read involve having Visual Studio installed or copying the files. Surely it's possible to compile the Web Deploy package without installing Visual Studio?
I have a TeamCity CI server without VS installed building a Web Project configured to also create a deployment package on successful build. However, for the life of me I can't recall if I copied those files manually or if they were installed by some component.
The relevant components I have installed are the following, if you want to give it a shot:
.NET 4.0 SDK;
Microsoft Visual Studio 2010 Shell (Integrated) Redistributable Package;
Visual Studio 2010 SDK; (Not the VS 2010 SDK SP1)
Microsoft Visual Studio 2010 Visualization & Modeling SDK;
Web Deploy 2.0;
I installed the VS Shell in order to be able to install the VS 2010 SDK which in turn was required in order to install the Visualization & Modeling SDK so that I was able to run T4 transformations on the build server.
With this components and configuring the following MSBuild properties DeployOnBuild=true;DeployTarget=Package to create the deploy package I had no problems, but as I said earlier I may have copied the files manually after giving up all hope of finding a more cleaner solution and now my brain is blocking any memory of such ill action.
Is it possible to build a Debugging Visualizer that can be used in multiple versions of Visual Studio?
A Debugging Visualizer has to reference Microsoft.VisualStudio.DebuggerVisualizers.dll and there is a separate version of the assembly for every version of Visual Studio. It seems that these versions are not compatible. For example, if I built a visualizer that references Microsoft.VisualStudio.DebuggerVisualizers v9.0, it can be used in Visual Studio 2008, but not in Visual Studio 2010.
I am looking for a way to target at least Visual studio 2008 and Visual Studio 2010 while maintaining only one project for the visualizer. Duplicating the project and changing only references to Microsoft.VisualStudio.DebuggerVisualizers will work, but it creates a maintenance horror.
If your code base is exactly the same for both referenced assemblies then I would suggest the same approach as I've suggested in this question: Visual Studio Installer -- Change application resource
The idea is to have 1 project where you will have a MSBuild property which VS to target and depending on this property you may reference either VS 2008 or VS 2010 DebuggerVisualizers assembly.
The only other solution I see is the one you've mentioned - having 2 separate project files to target different VS version. I do not think it will be that difficult to maintain two versions if you will not duplicate code. And you can avoid duplicating code by including code files as links into your projects.