I have a Visual Studio Solution with multiple projects. Few of them are of Visual studio 2017 and few are of Visual studio 2013. The difference is because of the use cases of the projects. Visual studio has the option to select toolset for each project. Now I need to create build through Jenkins using MSBuild. How can I set toolset for projects in MSBuild?
How to Use different versions of MSBuild for same solution C++
First, please make sure that VS2013 and VS2017 are installed in your local agent.
The Platform Toolset from VS IDE is stored in xxx.vcxproj file. It is stores as PlatformToolset xml node.
Like <PlatformToolset>v141</PlatformToolset>
v142 means VS2019, v141 means VS2017, v140 means VS2015, v120 means VS2013
So for your situation, you can just change the PlatformToolset.
Solution
So you can use -p:PlatformToolset=xxx in msbuild command line to specify a specific toolset version to build a project.
Note: this does not permanently change the value in xxx.vcxproj, but uses this specific value when building the project.
1) If you want to build the whole solution,
if you want to use the value in the whole solution(every project uses this toolset), use this:
msbuild xxx.sln -t:build -p:PlatformToolset=xxx
Or if you want to use different toolset for different projects in msbuild command line:
-- change PlatformToolset in every xxx.vsxproj file directly as you want and then build your solution
-- use msbuild script to combine all the projects of your solution and then build this script directly to get what you want. See my answer and change to use <Properties>PlatformToolset=xxx</Properties>.
2) If you want to build the project, you can overwrite the PlatformToolset in command line to specify it.
msbuild xxx.vcxproj -t:build -p:PlatformToolset=xxx
Related
Not too sure if what I'm asking here is possible, or if it requires an upgrade. My problem is that I have a local install of TFS 2013 (that is, on-premises), and all dev machines have now upgraded to VS2015. However, when using new features (such as $"test {teststring}"), we get build errors.
The build machine has both VS2013 and VS2015 installed, and is using the default build template (TfvcTemplate.12.xaml). Looking at the "Run MSBuild" task inside the build workflow, there doesn't seem to be any way to point it to one MSBuild or another.
Is it possible to hint to the build to use the later version of VS / MSBuild and, if so, how?
Try adding /tv:14 to the msbuild commandline arguments in your build template, if that doesn't work, edit the xaml file for your build process template and override the "ToolPath" property of the "Run MsBuild for Project" task. Or make that field configurable through further customization of the build template.
Set that path to C:\Program Files (x86)\MSBuild\14.0\Bin (or your equivalend location in case your machine uses alternate default directory names).
Has anyone experienced TFS Build 2015 V.Next building their projects in a different order than they set in the sln? We have a project that uses an exe that is created and we have set in the solution to build in a specific order. However when the build runs online it builds in it's own order and the file doesn't exist yet. Obviously I might switch it to be in two solutions but I would rather not have to modify the sln because of a nuance in tfs 2015.
So it turns out that the solution didn't support multiple processors because it built a file that it used as a .exe in the build steps. So it built the .exe in another process and then built the other .dll in another process.
Run msbuild with the following argument to resolve the issue:
msbuild.exe /m:1 {SLN}
I’ve been reading some articles (this one in particular: http://speaksql.wordpress.com/2013/06/07/a-journey-to-db-deployment-automaton-ssis-build-using-msbuild/) about using msbuild.exe to build and deploy an SSIS package (.ispac). I had no problem with that from my computer which has all the required assemblies, and only using the msbuild.exe command.
Once I tried to use the TFS Build Server I had some problems. First I realized that using a project with msbuild.exe (SSIS.MSBuild.proj) was not recommended with TFS 2013 since it was used with TFS 2008 and 2010. Anyway, I just wanted to make it work and it sounded plausible, but I had to use the TFSBuild.proj. That was not a problem, but my next problem was that the project I was being using (Microsoft SQL Server Community Samples: Integration Services) references a SQL Server assembly (Microsoft.SqlServer.ManagedDTS) which is not installed on my build server.
Then I realized that even if I managed to install that assembly on the gac, or referenced it on a relative path I would have a bigger problem next, I am using custom activities on my packages which I need to install using gacutil.exe on the host server, and I was wondering how to install, remotely, those dll.
That’s when I started to lose faith, and here I am, is there an “easy” way to implement continuous integration for SSIS packages without installing third party tools (http://remotegacutil.codeplex.com/ for example), and adding missing assemblies to the gac of a build server?
Did any of you have a similar issue? Did you solve it? How?
Thanks!
Use devenv.exe to build the ispac. Add an invoke process task and call out to devenv.
Add an Invoke Process to the Build Template, the one above shows a Sequence container, which assigns the path to the correct version of DeVenv to call, VS2010 /12 /13 etc. this is shown as hard coded but can be put into an argument, so it can be populated in individual build definitions. the one you can't see clearly is "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.com"
Next is the invoke Process, this call out to the specified devenv.exe and passes arguments used to build the ISPAC file.
The arguments are passed in localProject would get you the actual project you wanted to build in previous versions, you may have to do something different for 2013, due to the changes to the new templates.
this gives a TFS2012 way of doing it, as i say you may have to do something different to get the project that you want to build under 2013, but the build will run and an .ISPAC file will be generated.
at this point i would deploy the ISPAC using powershell, you may want to add additional scripts to the powershell calls to handle creating the SSIS Catalog and scheduling of the job.
deploying with Powershell can be found here Deploying ISPAC's with Powershell
I would like to add my Build Definitions to TFS Source Control. Is there anyway to do this?
Not really, no. If you're trying to track changes to your build definitions, you can use a couple of new commands in the latest releast of the Team Foundation Power Tools. The first compares two build definitions:
tfpt builddefinition /diff
This one exports a build definition's configuration to a text format, which you could then check into version control.
tfpt builddefinition /dump
Another option via powershell
https://gist.github.com/jstangroome/6747950
which basically uses c# types so should be easy enough to make into a linqpad or c# console app (or winforms or wpf)
used assemblies
Microsoft.TeamFoundation
Microsoft.TeamFoundation.Client
Microsoft.TeamFoundation.Build.Client
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.TeamFoundation.Build.Workflow.dll
We moved from TFS 2008 to TFS 2010.
With TFS 2008 I used _TEAM_BUILD_ in project file const to turn PostBuild event off when building by build server.
Now, when I create build definition with new format, without using tfsbuild.proj, but using Default template, it doesn't seem to work. I have PostBuildEvent running even though I am using same approach.
Any ideas how to achive same functionality, having PostBuildEvent running from Visual Studio and to be ignored on build machine?
Check for BuildingInsideVisualStudio. As you'd suspect, it's only defined when building inside Visual Studio. Alternatively, you could add "/p:_TEAM_BUILD_=1" to the MSBuild Arguments build process parameter of your build definition.