It it my understanding that it is still the simplest to use the <Exec \> MSBuild task and shell to TF.exe in order to TFS command line during MSBuild, especially if you don't want to create a dependency on custom build tasks or extension packs etc. (see Checkout from TFS with MSBuild)
Given that, what is the best path to use for tf.exe especially since different developers may have TFS2010 or TFS2012 mixed with VS2010 and VS2012 and also mixed with 64-bit workstations.
Is there parhaps a variable / path standard way to call the TF.exe command from MSBuild regardless of VS or TFS version?
You can see if a system is 64-bit by looking for the ProgramW6432environment variable.
And as long as users have chosen the default install path, TF.exe is still installed in the 32-bit part of Visual Studio even for VS2012. So the only thing you should need to look for is whether the user has 2012 or 2010 installed. That should be possible with the Exists condition:
<PropertyGroup>
<ProgramFiles32 Condition="$(ProgramW6432) != ''">$(PROGRAMFILES) (x86)</ProgramFiles32>
<ProgramFiles32 Condition="$(ProgramFiles32) == ''">$(PROGRAMFILES)</ProgramFiles32>
<VS10Dir>$(ProgramFiles32)\Microsoft Visual Studio 10.0</VS10Dir>
<VS11Dir>$(ProgramFiles32)\Microsoft Visual Studio 11.0</VS11Dir>
<TF Condition="Exists('$(VS10Dir)')">"$(VS10Dir)\Common7\IDE\TF.exe"</TF>
<TF Condition="Exists('$(VS11Dir)')">"$(VS11Dir)\Common7\IDE\TF.exe"</TF>
</PropertyGroup>
...
<Exec Command="$(TF) checkout ..."></Exec>
tbergstedt has a solution is likely more robust and can be adapted to other problems too. I did discover that there is a shortcut for this, since the TF.exe executable is also in the Developer Environment path $(DevEnvDir). See below:
<PropertyGroup>
<TfCommand>"$(DevEnvDir)\tf.exe"</TfCommand>
</PropertyGroup>
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
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).
I have a system with 8 options to deploy and manage all these .config files are causing problems for the team
So I found a Jenkins plugin for installshield. But i don't know how change the product version and product code using jenkins.
In VisualStudio, I change this options in "ProjectInstall > GeneralInformation > Product Version.
What I want to know is:
How change these information by code (jenkins configuration or Nant, or something else)
I'm using "VisualStudio 2013" and "InstallShield Limited Edition for VisualStudio 2013"
I've never used the IS plugin for Jenkins but it's probably just a wrapper for ISCmdBld.exe. If so, it probably exposes the -y and -z arguments (bottom of page) for overriding the ProductVersion and other named properties.
That said, I haven't called IsCmdBld.exe in years. InstallShield has nice MSBuild support which means you can do all of this in MSBuild and just build the .SLN like any other Visual Studio project.
Is there a way to convert a TFSBuild.proj file into a simple MSBuild without the TFS stuff? Our teams are wanting to move away from TFS in favor of a git/jenkin approach and I'm trying to see if there is an easy way to convert the tfs scripts. I know that the TFSBuild.proj is built on top of MSBuild and I can actually call msbuild TFSBuild.proj to get it to work. My issue is that our new ci server will not have tfs on it so I'll get errors like this:
error MSB4019: The imported project "C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
Thoughts? I'm guessing I'm probably just going to have to manually convert these.
You can't convert TFSBuild.proj into simple MSBuild, because it already is. When you queue a build in TFS the Build Agent is just doing "msbuild.exe TFSBuild.proj". Maybe with some additional parameters (defined in the Build Definition) and of course preparing the folders before.
The easiest solution to your problem is to install a Visual Studio on the server, this will bring all the requirements for builds, like MSBuild, frameworks and SDKs.
I have an MsBuild file which shells out to TFS using tf.exe for a few things. Unfortunately the tf.exe file has been installed to different locations on the developer PCs and the build server.
I could really do with a way of detecting where the tf.exe file is located within my script in the same way you can do $(MSBuildExtensionsPath32) etc. Is this possible?
Thanks as always :)
Does the environment variable VS100COMNTOOLS point to the correct path for visual studio?
E.g.
VS100COMNTOOLS=C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\
So then all you need is $(VS100COMNTOOLS)..\IDE
<Target Name="Build">
<Exec Command=""$(VS100COMNTOOLS)..\IDE\tf.exe""/>
</Target>
or however you want to tidy it up.
The environment variable changes depending on the version of Visual Studio:
%VS110COMNTOOLS% - Visual Studio 2012
%VS120COMNTOOLS% - Visual Studio 2013
%VS140COMNTOOLS% - Visual Studio 2015
Seems they changed location again in Visual Studio 2017.
It was not in any of the above locations on my machine.
I found TF.exe instead at:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer
(Some users may find in the Professional folder instead of Enterprise folder: C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\tf.exe)
Apparently the environment variable is no longer set by default in VS 2017.