My solution consists from C# projects. I need one build definition that builds the whole solution. Most of projects have project to project referencies (like ProjectReference Include=) but some projects have explicit dependencies stored in solution file (ProjectSection(ProjectDependencies) in sln file).
old connect.microsoft.com article
claims that MSBuild ignores order specified in solution "Project dependencies". Are situation the same in TFS 2015? What MSBuild version does TFS 2015 use nowadays?
Does TFS 2015 Team Buider that uses MSBuild order building of projects properly according to dependencies stored in solution file?
It does, at least on solutions I have seen (consisting of 10-15 projects) dependencies never give issues.
Additionally TFS2015 have Visual Studio build step which is run not by standalone msbuild but Visual Studio installed on the build server. Naturally this build step completely replicates your local build behavior.
Related
I followed the instructions on the "SonarQube Setup Guide for .NET Users" (http://redirect.sonarsource.com/doc/sq-setup-guide-for-dotnet-users.html) to setup a SonarQube 5.1.2 server and integrated with TFS 2012. Even though the document describes how to integrate SonarQube with TFS 2013 XAML builds and TFS 2015 Build vNext, I was able to somewhat integrate it with TFS 2012 XAML build. Here are the sequence of steps in the TFS 2012 XAML.
call InvokeProcess build activity (with WorkingDirecotry set to the directory containing the VS Solution file to be compiled such as C:\Builds\...\ClassLibrary3 to call MSBuild.SonarQube.Runner.exe begin ... (MSBuild SonarQube Runner version 1.0.1)
Call Microsoft MSBuild activity to compile 1 or more VS Solutions such as C:\Builds\...\ClassLibrary3\ClassLibrary3.sln
call InvokeProcess build activity (with WorkingDirecotry set to the directory containing the VS Solution file previously compiled) to call MSBuild.SonarQube.Runner.exe end
The problem is that I can only analyze one compiled VS Solution even if multiple VS Solutions are compiled. This is because the working directory must be the same when calling MSBuild.SonarQube.Runner.exe and MSBuild. The MSBuild activity's working directory is set to where the VS Solution file is located but will differ for each VS Solution compiled but MSBuild.SonarQube.Runner.exe can only specify one working directory. Is there a way to analyze multiple VS Solutions? I don't think there's a way to change MSBuild activity's working directory is there? Thx.
The best way to proceed is be have one project in SonarQube for each of your solution, and use the Portfolio Management plugin (commercial) to perform the aggregation of all these projects on the server side to offer the big picture. See http://www.sonarsource.com/products/plugins/governance/portfolio-management/ & on Nemo how it integrates all Apache projects for example: http://nemo.sonarqube.org/dashboard/index?id=Apache
Another way would be to craft a *.proj file that will include all other projects to build.
Another way, which I wouldn't recommend, is to invoke MSBuild.SonarQube.Runner begin for every solution that you build, then movie the contents of every .sonarqube\out folders to a single one (aggregate it), and call MSBuild.SonarQube.Runner end from that location.
Another way would be to upgrade to TFS 2015, and check how its MSBuild task behaves.
I am working with integrating in MSBuild xml tasks file in to a visual studio 2012 solution. The file performs 2 tasks, 1 to validate against StyleCop, the other to run FxCop analysis. I have created the msbuild file from tutorials on the web.
My question is, where should the file be stored on the file system? I presume its outside of the solution. How do I set up the solution to run this msbuid file? I use TFS for source control and TFS Build 2010 for CI so I am looking to integrate it in to this also.
Here is the way that I have our source control tree laid out where I work:
Root
-- Artifacts (Reports folder for build. Items are not checked into TFS)
-- BuildOutput (location where all compiled code is sent. Items are not checked into TFS)
-- BuildScripts
-- ConfigFiles (config files used for different kinds of builds)
-- MSBuild (MSBuild scripts that I have written for our build)
-- MSBuild Extensions (MSBuild extension that I use as part of my build)
-- Database (folder for all database related items)
-- src (folder for all DotNET source code)
-- ThirdParty (folder to hold all of our third party dependencies like NUnit, Specflow, etc)
This has worked out fairly well for us.
Typically, when you want to integrate things like styleCop and FXCop you will include them as steps in your overall build process and not directly into a project or solution. For example, the build process that I manage has 12 different steps that it performs. I do things like 1) compile code, 2) run unit test and code coverage, 3) run integration tests, 4) run duplicate finder, etc. You would want to set up the same kind of thing as part of your build process.
I do not have much experience with TFS Build (I started using TeamCity by JetBrains over TFS Build) but you should be able to modify your build template to integrate your MSBuild scripts into your build process. I also think there are some extensions for TFS Build that allow your to execute StyleCop and FXCop directly within the build template.
Hope this helps.
I have an WCF project that if i use the Visual Studio option "Publish" gets published fine.
But if I use the MSBuild parameter DeployOnBuild it does not get published correctly. I'm getting an "Could not load type" error, and all of de dlls are there.
I using the MSBuild in a Build Definition in order to have a Continuous Integration Build.
The build parameters I'm using are:
/p:DeployOnBuild=true
/p:DeployTarget=MSDeployPublish
/p:MSDeployPublishMethod=RemoteAgent
/p:MsDeployServiceUrl=http://host/msdeployagentservice
/p:username=#####
/p:password=****
My main problem with this scenario is that the build targets are the same, and the build definition actualy publishes the files, but somehow they are not the same.
Any insights ???
I dont like to answer my on question, but since it may help someone else is the cause of the problem.
One of the projects had a post-build command to copy the resulting
dll to another project specific directory (its not a reference
because it using dependency injection in runtime).
The dlls did not get checked in to TFS because they are not checkout automaticaly
The
Continuous Integration Build fetches the sources from TFS and the dlls are out of sync
The solution was to checkout the dlls before the build so that the checkin updates them
I am trying to use MSBuild to compile a solution with a few BizTalk 2010 projects (maps, schemas, pipelines) and a few non-BizTalk projects (console app, web app).
MSBuild gets triggered by Nant. The problem is that, everytime I run the compilation, the BizTalk projects get recompiled (and the assembly version number changes). This happens even if there are absolutely no changes to any part of the entire solution.
In other words, If I build the solution once, the assemblies get created fine. Immediately, if I build again, the non-BizTalk assemblies do not get re-created (MSBuild reports Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files). But, the BizTalk assemblies happily get re-created. This is annoying.
Please can someone help/advise?
BizTalk Server 2009 and 2010 .btproj project files are, indeed, MSBuild projects. As you have noticed, the way standard BizTalk targets are authored prevents incremental build of BizTalk projects.
Fortunately, MSBuild is extensible and can be customized in many ways. Please, follow the instructions on this post to to alter the standard build logic of .btproj files in order to add incremental support for your build system.
We have migrated few projects from TFS2008 to TFS2010 by using the method-
1.Attch TFS2008 DB to TFS2010 DB
2.Tfsconfig import
3.Delete the project not required.
There are few projects in the migrated projects which use VS2005. They do not want to do any change in their project and want to use VS2005 to work with migrated projects. We have applied couple of patches in VS2005 and now they are able to access the TFS2010 projects from VS2005.
However we are clueless about the build configuration. We have configured build server for their Collection...now what configuration needs to be changed in TFsbuild.proj to make the build run again.
Is there any more steps required to make the build work?
Any help would be very much appreciated.
Thanks Upfront.
Kabir
If you have not had a build definition for you TFSbuild.proj then you will need to create one. In your build definition, you will need to choose UpgradeTemplate.xaml as the build process template. In TFS 2010 this template is used to run legacy build definitions.
See how to run build with the UpgradeTemplate.xaml here.
I also found this useful post in the MSDN Build Automation forum that tells you the differences between 2010 and 2005 build processes.