We have a TFS 2012 instance and a build agent w/ VS 2017. I am trying to modify a XAML build template to create a nuget package from a given project. I am required to put the changeset number in the description of the package but I am unable to get the correct value.
I have an InvokeProcess activity in the AgentScope of my template which runs a PowerShell script to pack the package. I have tried getting the TF_BUILD_* environment variables but none seem to be populated. I also tried BUILD_SOURCEVERSION with no luck. At the moment I am passing in the BuildDetail.SourceGetVersion value but that is returning the current changeset for the entire team project, not the specific project I am building.
What am I doing wrong? Are those variables only on the TFS server and not on the agent (build server)?
TFS 2012 build changeset version in PowerShell script
According to the article Build Script Hooks for TFS 2012 Builds:
When I created a script for a 2013 build to version the assemblies, I
relied on the fact that the 2013 build sets some environment variables
that you can use in your scripts.You can see I’m getting
$env:TF_BUILD_BUILDNUMBER. Well, in the 2012 workflow, these variables
aren’t set, so you have to add an activity to do it.
That the reason why you tried getting the TF_BUILD_* environment variables but none seem to be populated.
So, to resolve this issue, you can just to follow the steps in Challenge 2 to set it.
Or, you can use TFS API to get the latest changeset number in your TFS version control:
Please see this thread for detailed information:
Programmatically retrieve the latest changeset number available in a workspace
Then you can write another small program to modify your description field in the .cs file be the changeset number you get in above.
Hope this helps.
Related
I can successfully build my project on local. When I do via VSTS then build is not successful. I get an error message that a dll cannot be found in my sub project. And it is Rapportage.Logic. The missing dll is used by Rapportage.Logic
Does anyone know the reason?
Most of the time this type of error comes down to:
files present/edited on developer machine but not commited (usually the .csproj file)
subtle differences between Visual Studio build and MSBuild.
I would try the following:
copy the MSBuild command from Azure DevOps logs (the line containing MSBuild.exe)
change the paths in the command to match your dev environment (e.g d:\a\1\s to c:\code\myproject)
run this command
If this command fails with the same error as the build you the problem is a difference between MSbuild and Visaul Studio.
If it succeeds, you most likely have missed a commit.
Build is successful on my local but not on vsts azure DevOps
It depends on how you add ReportViewer references.
If you add the ReportViewer reference manually, you need add the ReportViewer reference to the solution/project folder, then add the reference from that folder. In this case, the path of references are not hard-coded paths. Besides, you need add those/this ReportViewer reference to the source control and submit to the Azure devops repos.
If you add the ReportViewer reference by nuget, you need add the nuget restore task to restore those nuget packages. I could see you are using nuget restore task from your build log (The second image.), but on the build definition, I did not see you have add that task (The 3rd, 4th images.). So, make sure you have restore those packages when you build on the Azure devops, and you could check the restore task if those nuget packages are restored.
Hope this helps.
I have Continuous integration checked for my folder in TFS which triggers a build in TFS2015 . Now as part of by Build Definition, I want to add a step which would identify and pull only those files which were checked in as part of the changeset which triggered the current build and copy them to a target location.
A powershell script may be? Help please
You can add a Powershell script task in your build definition to do this. A simple script for your reference:
$changesetid = $Env:Build_SourceVersion
$TFSURI = $Env:System_TeamFoundationCollectionUri
$tfs = [Microsoft.TeamFoundation.Client.TfsTeamProjectCollectionFactory]::GetTeamProjectCollection($TFSURI)
$vcs = $tfs.GetService("Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer")
$cs = $vcs.GetChangeset($changesetid)
foreach ($change in $cs.Changes)
{
$change.Item.DownloadFile('D:\a\test\' + $change.Item.ServerItem.Substring(1))
}
This code just get the changed items, if the changeset includes other changes like deletion, you may need to add code to check this.
And you also need to import the TFS Client Library to use this script, refer to this link for details: PowerShell and TFS: The Basics and Beyond.
This isn't possible in TFS 2015. TFS 2017 has introduced the ability to "don't sync sources", after which you can perform your own get operation. You could try cloaking the whole repository on the repository tab and then creating a CI TFVC Include trigger definition on the trigger tab to recreate this behavior.
Then you can use the tfpt getcs option to get the changes of the changeset. You should be able to get the version from the builds Build.SourceVersion variable. You can get tfpt by installing the Team Foundation Server Power Tools 2015 and Team Explorer 2015 on the build server.
I am successfully deploying an SSDT package in my VSTS release. If publishing directly from Visual Studio, there is a flag "drop_objects_not_in_source" under advanced settings. However, cannot figure out how introduce this in my CI/CD pipeline. There are a bunch of refactoring tools but none address this. So, I am stuck with object on the sql server that have been deleted.
Any suggestions?
Pass the command line argument /p:DropObjectsNotInSource=true when publishing the database or use a publish profile that contains the setting.
Given Microsoft Visual Studio Team Foundation Server 2015 (on premises), is it possible to interact with the build and release process remotely with powershell?
For instance, we have CI builds in place with various triggers...e.g. a working branch is merged to a feature branch will kick off a build. If I am working on a one off branch that is not part of the trigger set, can I queue a build with a script that I execute on my machine? Can I do things with the results of that build...e.g. queue the release that is created as a result of the build.
yes you can via the TFS Rest API.
I implemented the following Task with Powershell: https://marketplace.visualstudio.com/items?itemName=benjhuser.tfs-extensions-build-tasks
You can have a look at the source as well.
You can find the references to the API on msdn:
https://www.visualstudio.com/en-us/docs/integrate/api/build/overview
Regards
I am trying to get the Source Version Changeset number from TFS. I am using a PowerShell script to add the AssemblyInformationalVersion. I have tried using $env:TF_BUILD SOURCEGETVERSION but this dosen't work it just return blank. We are using TFS 2012 with a custom build template calling the PowerShell scripts (http://www.colinsalmcorner.com/post/build-script-hooks-for-tfs-2012-builds)
I really want to keep everything within the PowerShell Script
No, this can't be achieved simply by an environment variable in a powershell script . You need to create a custom task, follow the steps below to have a try:
Get the latest changeset number in your TFS version control. You can
just get it by using TFS API. Please see this thread for
detailed information: Programmatically retrieve the latest changeset number available in a workspace
You can write another small program to modify your FileVersion field
in the .rc file be the changeset number you get in Setp1.
Or you can try the method descried by Ivan's answer in this question Versioning .NET builds
Add more similar quesitons in SO for your reference:
Getting TFS to put the changeset in the assembly version
TFS and msbuild version number with last changeset
Take control of assembly numbering during a tfs build
The answer is in the article you referred to(The Challenge 2 – Environment Variables).
When I created a script for a 2013 build to version the assemblies, I
relied on the fact that the 2013 build sets some environment variables
that you can use in your scripts.You can see I’m getting
$env:TF_BUILD_BUILDNUMBER. Well, in the 2012 workflow, these variables
aren’t set, so you have to add an activity to do it.
That's why $env:TF_BUILD SOURCEGETVERSION returns blank, so you just need to follow the steps in Challenge 2 to set it.