So I'm trying to setup builds for our different staging environments using TFS 2010 and msbuild. One of our staging environments uses a different version of a dll, lets call it "ThirdParty.dll".
So I want a build to target that environment, but this build will have the projects build against this older version of the "ThirdParty.dll". This dll is not in the gac, is not strongly signed, and no I can't change the enviroments to use the same dll.
So is there a way within TFS and msbuild to automate this? What do I need to look into to get started?
You should be:
storing the libs in source control
using Condition='<config=xx>' on the ItemGroups and/or properties within the MSBuild file to parameterise the location for the Reference as appropriate
Related
In my mind i have a process I want todo with TFS, but in reality I dont seem to be able to work out how todo it.
Se we have a small team of developers, we build standard components (DLLS) that we use in lots of bits of software. When we make a change to one (StandardLib) for example we can get a build to generate in TFS, but is there a way in Visual Studio of linking our references to the latest build so we always use the latest version of the DLL, without having to build it locally on our PC's
Any help is much appreciated.
You can update the build definition to create nuget packages for the dll files and publish the nuget packages to a feed. And then use nuget to manage the references in your project. When there is a new version of the dll files, you just need to run update package command to update the reference to the latest version.
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 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.
I'm a newbie to configuration management and I'm required to implement a solution wherein I need to publish a new version of my Windows application on shared Network drive using Teamcity's Trigger.
We already have a continuous integration Teamcity server which is used for continuos build integration. Is it possible to publish a new version everytime along with the build using MSBUILD or something?
Thank you so much for reading.
Absolutely. I believe you already have a Build/Compile MSBuild target.
So now you can create Deploy.targets which simply executes a <Copy> MSBuild Task.
InputFiles attribute specifies files which are produced by Build/Compile target and OutputFiles would be the destination network folder path.
After that you have to make Deploy target to be dependent on Build target by specifying DependsOn="Build"