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).
Related
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
I have installed TFS 2018 Community and was trying to publish a project to plesk domain using one of the publish profiles in the arguments of msdeploy task as shown in the picture below but it only build the project but did not publish it like I thought it would
Generally if you can run the msbuild command successfully with the arguments on local VS, then it should be also available in TFS.
So, please check below things to narrow down the issue:
Just make sure you have the same components installed and configured
on your build agent machine.
Make sure you have the correct configuration for your build
definition.
Based on your screenshot above, just try to set the correct buildPlatform and buildConfiguration (consistent with your project settings in VS).
Also verify that if you have checked in the PublishProfiles, and check the first Get sources step, make sure the system can get the sources and PublishProfiles during the build process.
This article for your reference : TFS 2015: deploy website to IIS without installing extra add-ons to TFS
UPDATE:
In order to use Publish Profiles on the build server, you have to have some of Visual Studio's prerequisites. Make sure you have installed the full version of Visual Studio on the build agent machine.
Besides, you can try with below arguments (Just change the PackageLocation value accordingly) :
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"
Referecne: Working with Web Deploy and Release Management for the deployment.
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
With TFS 2010 build controllers/agents there is the option to set a version control path to custom assemblies that will be available on all build agents. The documentation states that this works for custom workflow activities as well as custom MSBuild tasks (about in the middle of the page):
http://msdn.microsoft.com/en-us/library/ee330987.aspx
Does someone know how this feature can be used for custom MSBuild tasks? I checked into version control an assembly with a custom task and set the option on our build controller to the correct version control path. But I don't know where the assembly will be on the build agent and how I can reference it from within my MSBuild targets file (i.e., UsingTask).
I even searched for the assembly on the build agent but could not find it...
Any help is very much appreciated!
Here's the answer: the contents of the version control path is stored on the build agent in this folder:
C:\Documents and Settings\<user>\Local Settings\Temp\BuildAgent\<num>\
where <user> is the account that runs the build service, and <num> is the number of your build agent.
I have no clue why it was not there at first and what caused the build agent to finally fetch it from source control. Maybe just some patience is required if the version control path is changed or its contents gets updated?
It's possible, but the simpler solution is to just check your custom MSBuild tasks into a shared location in version control, then map that location into the source configuration for your build. That will also make it easier to use the MSBuild tasks for both desktop and server builds.
I use $(Temp)\BuildAgent\$(BuildAgentID) in TFS 2012. Note that in TFS 2010 it was slightly different. Don't expect this to be stable for future releases.
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.