I have a custom MSBuild task that implements an output property. How can I retrieve the value of that property on the build server in build workflow activities that occur after the MSBuild activity has completed?
Thanks,
James
Write the property to a file and read it in your build activity. The name of the file should be passed to msbuild on the command line to reduce coupling between team build and msbuild
Related
I am having hard times attempting to perform the simplest operation: run the custom MSBuild script (placed within dedicated "BuildScripts" folder) from the Lab test running build definition. What it is supposed to do prior to test execution is to trigger the child build, get the built sources and perform the modification of the config file by the means of MSBuild script. And that is what I struggle with. Supposing I have specified the build scripts folder among source settings (mapped to $(SourceDir)) and I use the MSBuild activity for running the script, what do I specify in the path for project file location?
Would appreciate any hints you might share.
Thank you.
If I understand your requirement correctly, you can select the MSBuild script file in Build Process as soon as you have uploaded the file into Version Control.
Clicking the button below:
You will get a dialog to select the solution or project you want to build:
And then click "Add..." button, you will be able to select the file from Version Control.
Never heard the "MSBuild script". If you mean to run powershell script during the build. So where do you want to specify the path for project file ? In the script or the configuration of the build template ? Suggest you to provide a screenshot.
Moreover, you can use "invokeprocess" workflow activity to invoke powershell script during the build.
I have an automated build set up in tfs2015 using a web build definition (i.e. not a xaml build definition) and I am looking to pass a custom property to the msbuild command.
I have tried setting a variable in the definition but this is not used in the build process.
the msbuild command argument that I need to pass is /p:myProperty="bob"
The build definition has variables:
yet when I build I get the msbuild command:
C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe "C:\Build\Agent\_work\5ad80936\FullSolution.sln" /nologo /m /nr:false /fl /flp:"logfile=C:\Build\Agent\_work\5ad80936\FullSolution.sln.log" /dl:CentralLogger,"C:\Build\Agent\agent\worker\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll"*ForwardingLogger,"C:\Build\Agent\agent\worker\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll" /p:platform="any cpu" /p:configuration="release"
So the BuildConfiguration and BuildPlatform variables are used in the way I would like myProperty to be used, yet this variable is ignored.
I have tried prefixing my variable name with 'Build', but this made no difference.
Can anyone help?
Incidentally, if run the msbuild command locally and append the required argument the build does exactly what I want.
I have found the answer, the variables are simply that, variables. To use those variables as msbuild command line arguments requires the setting of another part of the build definition:
On the build tab set the MSBuild Arguments parameter to use the variable that you have created:
The part in the $() is the variable name used in the TFS build definition, the portion before the = is the name of the property in your msbuild script. These do not necessarily need be the same
I have an MSBuild task that populates a variable that I would like to use later in the build process (specifically as an argument in a command line build step).
Is there any way to access an MSBuild variable in subsequent build step?
You can use the ##vso[task.setvariable]value logging command from your MSBuild task to pass the variable to VSO like this:
<Message Text="##vso[task.setvariable variable=myvariable;]$(MyMSBuildProperty)" />
You can use the variable in a subsequent build step by using $(myvariable) in the input fields of the command line build task.
Regarding the announcement of SonarQube integration with MSBuild and Team Build, can anyone advise on the relationship between SonarQube Runner and SonarQube.MSBuild.Runner? I'm unclear whether SonarQube.MSBuild.Runner replaces SonarQube Runner or whether it sits on top of it.
#Techtwaddle is correct: the MSBuild.Runner invokes the sonar-runner.
The MSBuild.Runner v0.9 does the following:
fetches configuration settings from the SonarQube server;
gathers information during the MSBuild phase;
generates a sonar-project.properties file;
invokes the sonar-runner to carry out further analysis.
Some of the analysis is now performed before calling the sonar-runner. For example, FxCop analysis is now happens as part of the MSBuild phase rather than being invoked from the sonar-runner.
Currently, you have to manually install both the sonar-runner and the MSBuild.Runner. Work is planned to change this so you will only need to install the MSBuild.Runner. See http://jira.sonarsource.com/browse/SONARMSBRU-42.
I need to setup a scheduled task in Windows Task Scheduler (v2.0 on Windows Server 2008 R2) right after my web site deploys.
I am using TFS 2010 to build my application, and apparently my MSBuild Arguments contain arguments /P:DeployOnBuild=True /P:DeployTarget=MSDeployPublish /P:CreatePackageOnPublish=true /P:MSDeployPublishMethod=WMSvc.
I know that I can use Schtasks.exe to setup a scheduled task via command line, I also know there is a runCommand provider for MsDeploy. So I thought I could use runCommand to run Schtasks.exe with required parameters.
My question is how I do it in TFS and MsBuild. I assumed I could pass some parameters to MsBuild, and they would be transferred "as is" to MsDeploy, but I could not find how I do it.
If it must be after the build, you'll need to use the postSync msdeploy argument to execute a runCommand. Since postSync is not available from Visual Studio's MSBuild tasks, you'll need to generate a package and then run the generated cmd file with the postSync argument tacked onto the end.
Package.cmd -postSync:runCommand="c:\windows\system32\schtasks.exe arguments"
If it should be after the build, you can include an additional provide by adding the following to your publish profile (pubxml), .wpp.targets file or your project file:
<ItemGroup>
<MsDeploySourceManifest Include="runCommand">
<Path>"c:\Windows\system32\schtasks.exe" "Arguments here"</Path>
</MsDeploySourceManifest>
</ItemGroup>
It's not officially guarantees that providers run in order, but in practise they do. You might need to hook a target into the right event, though, so you can register your runCommand after the other providers.