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.
Related
Some original info was changed to make the post more focused on the real issue after it was found.
These are some of the details of the current environment. I listed these only because questions were raised in other posts to determine what was and was not working in the current environment:
Upon check-in TFS 2017 successfully builds a web project on the build agent.
A VS 2017 publish profile can manually transform the project properly
The build machine artifact location includes both the transform and profile files
The artifact location is shown below:
I have researched this in depth on Microsoft's VS site, SO and other forums, but there are so many different answers, many of them for older versions, I have been unable to piece this together. As a result I have several sub-questions.
1) Can transforms be engaged in both Builds and Releases?. I read that transforms are applied during the publish process, not the build process, and that made me wonder if it is even possible to do this during a Build. But then when I was exploring releases, I saw all the same tasks usable in a Build, which suggests I can publish with a transform in either Build or Release. Is that correct?
2) Does TFS 2017 require a lot of special handling to engage a transform file? Some of the posts instructed the editing of the .proj file. I wanted to get a confirmation before doing that kind of detailed manipulation, especially given the improvements in TFS 2017.
The following information is the state of the current build definition named "confPanner-CI". The shaded PS script was successfully used to upload to the hosting location to test the whole process, but that is not adequate for the task at hand which requires transforms to be applied:
The full MSBuild Arguments which also created a temp location for the powershell script are:
/p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:DeleteExistingFiles=True /p:publishUrl=c:\ConfPlnrWeb
If I were to add a task for publishing I saw the Publish Build Artifacts task:
But none of the settings as shown below seem to relate to transforms:
The bottom line question is: How do I configure the build so the web project upload has the proper web transform applied?
Update: The following added after the answer below led to at least one place where VS transforms can be applied during a build, and presumably also a release.
Inside the MSBuild Build solution task set the Configuration as shown below:
Publish Build Artifacts task is used to publish the related artifacts ( The “a” working directory contains the artifacts (also known as the “drop”) that are uploaded at the end of the build) to Visual Studio Team Services/TFS or a file share.
Usually it should be a package and be used in a deploy task such as Deploy: WinRM - IIS Web App Deployment or Azure App Service Deployment to achieved the deployment.
1) Can transforms be engaged in both Builds and Releases?
Yes, you could also do this in a build pipeline with the useage of build deploy task. You need to add the task after the publish build artifacts task.
2) Does TFS 2017 require a lot of special handling to engage a transform file?
update
The BuildConfiguration variable is different in TFS 2017, it's inside
the MSBuild task! Transforms are now applied according
to the MSBuild task Configuration setting.
Edit the .proj file is a method to do the transform. If you don't need to change the transform, it will auto do it during the build.You could also use some 3-rd party task/extension for extra transform such as: XDT Transform
Usually we separate the build and release for the deployment, cause it's easy to configure multiple environments and easy to debug issue. You definitely could do this only in build but with a bloated process. You could refer this tutorial: Build and Deploy Azure Web Apps using Team Foundation Server/Services vNext Builds.
For a separate build and release solution, you could take a look at this blog: Using web.config transforms and Release Manager – TFS 2017/Team Services edition
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 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.
I am working on MSBuild 2010 and TFS 2010. Heard that one can also use MSBuild apart from using Windows Workflow. My question is how? How do i create a MSBuild project and see the .proj file just like i used to in TFS 2008/ MSBuild 2008
If you have builds that you've created in TFS 2008 that you want to use now, create a build definition that uses the UpgradeTemplate.xaml. This template was created for porting over earlier TFS builds and lets you specify the TfsBuild.proj file that was used in TFS 2008.
Other than that, if you are just looking to use MSBuild scripts instead of the workflow in your build process, you can do that as well (though it is more difficult now.) In VS 2010, you can specify what you want to build when creating a build definition - it defaults to solutions in source control but it can be any msbuild script. Just select an msbuild script that you've created and go from there. For this route, I would recommend the DefaultTemplate.xaml, which you will definitely need to modify along the way.
I've noticed projects such as Msbuild Extension Pack and MsBuild Community Tasks give msbuild the power to install assemblies, sql, and setup IIS. These features seem to be oriented to doing installs and not builds.
So I was wondering how many people out there are using msbuild, perhaps in conjunction with Cruise Control.Net to do installs on staging environments?
I use MsBuild to build, and part of the build process runs Wix to create an installer(MSI) which is used to deploy to production.
I wrote up a little sample of templating configurations for different target environments with msbuild: http://blog.privosoft.com/2010/10/msbuild-environment-sandboxing.html
We use CC.NET & MSBuild to build and then also to publish to our dev and stage environments, however we do not have the push live on CruiseControl.NET, we run that MSBuild by hand. We just thought it would be way to tempting with a button to publish live ;) It took probably 2 or 3 revisions to get our MSBuild set up right. But now everything is in one file, and everything is based on Targets and Properties to do all the work. About 6 months ago, was what should be the last update and that was a multi-server push so we are ready for scaling up. We can now push any combination of parts to any combination of servers. So if we want 5 database servers, 3 contenet servers, and 2 web servers we have that ability. No need to use anything else. MSBuild can do it.
I created a deployment system where a central coordinator can:
- identify the right target server for a given component (e.g Windows service goes to a given server, web services go to another, etc.)
- perform a PsExec of a deployment MSBuild script on the target server
- the deployment MSBuild script is responsible for:
a) downloading the right component package (in my case a .zip)
b) backing up previous versions of the component
c) extracting the package to the right place
d) tailoring the installation steps to the type of component to deploy (e.g. needs to perform an Exec task of installutil.exe on a Windows service )
e) logging the result of the deployment
This system is built using a mix of:
- core MSBuild tasks
- [Tigris MSBuild community tasks][1]
- [MS SDC tasks][2]
- and custom tasks
The system allows us to perform consistent deployment of complex apps across partitioned environments (e.g. DEV, QA, UAT, etc) made of virtual servers.
I use MSBuild to build a fairly large client/server application. I use InstallShield 2008 to create a separate client and server install set.
By adding a custom target into the build process you can combine the creation of the installers into the build.
I would recommend that you create and test the build and the installer separately, before attempting to integrate the two.
I know this is an old question... but...
I am currently using MSBuild with MSBuild Extension Pack (http://msbuildextensionpack.codeplex.com) to do my entire deployment. The database portion is handled with the VS database command-line tool (vsdbcmd.exe - http://msdn.microsoft.com/en-us/library/dd193283.aspx). That Extension Pack is pretty amazing, and is letting me build web sites, app pools, Windows services, update config, and much more.
I've also put Team City agents on the test servers, so I can deploy as part of a build chain (introduced in version 7 of Team City). And running my deploy MSBuild script is super easy from Team City.
I used to use MSBuild, now I'm using PowerShell. MSBuild is a build language. It is painful to script in. There is a lot I wanted to do in it that were difficult and sometimes impossible.
Over the past year, I've created an PowerShell module somewhat equivalent to MSBuild Extension Pack called Carbon.
I strongly, strongly encourage everyone out there to learn and use PowerShell.