问题
I am distributing only binaries which were built by one of my TFS build definitions and each build receives a unique version number (1.0.$yy$dayofyear.$rev). The name of the build name contains this version number. The version number is set by a PowerShell script as the assembly version and the file version of the binary. I have only a build result rentention (including the built binaries in my drop folder) of 60 days and now I am wondering: How would I possibly figure out for some version number which is one year old which changeset it was built from so that I can have a look at the source code or rebuild exactly the binary? Do I have to add the changeset info somehow during my build explicitly? Do I have to encode the changeset number in my version number which is set during the build? Both ideas don't seem very ingenious.
回答1:
You could add a powershell script or extension task which will generate release notes as part of TFS vNext build. You will get something as below:
And then you could store it, for the source code take a look at this blog
回答2:
Preface: XAML builds.
You can have visibility into all your build products by creating release/hotfix branches, and having build definitions specific to those branches. It's easy enough to clone a build to a branch, and use version numbers as part of your binary stamps. I prefer to use a branch version number approach, and stamp my binaries with that version number. As long as you're creating unique build definitions for the binaries in each branch, you'll be able to easily view past builds, and see exactly what changesets are associated with it.All you need is the binary's version number, and you'll be able to trace it back to source easily.
回答3:
I finally came up with a PowerShell script that I hook into my build definition as an additional build step just after a step that is similar to the one proposed here which sets the version attribute in all AssemblyInfo.cs
files:
$systDefinitionId = $env:SYSTEM_DEFINITIONID
$buildDefVersion = $env:BUILD_DEFINITIONVERSION
$buildDefName = $env:BUILD_DEFINITIONNAME
$buildSourceVersion = $env:BUILD_SOURCEVERSION
$buildSourceBranch = $env:BUILD_SOURCEBRANCH
$SrcPath = $env:BUILD_SOURCESDIRECTORY
$AllVersionFiles = Get-ChildItem $SrcPath AssemblyInfo.cs -recurse
$AllVersionFilesCount = ($AllVersionFiles | Measure-Object).Count
Write-Verbose "Updating $AllVersionFilesCount AssemblyInfo.cs files in path ""$SrcPath"" with source information." -Verbose
Write-Verbose "ID of build definition: $systDefinitionId" -Verbose
Write-Verbose "Version of build definition: $buildDefVersion" -Verbose
Write-Verbose "Name of build definition: $buildDefName" -Verbose
Write-Verbose "Changeset to build: $buildSourceVersion" -Verbose
Write-Verbose "Branch to build from: $buildSourceBranch" -Verbose
foreach ($file in $AllVersionFiles)
{
(Get-Content $file.FullName) |
%{$_ -replace 'AssemblyProduct\(""\)', "AssemblyProduct(""$buildDefName / $buildSourceVersion"")" } |
%{$_ -replace 'AssemblySourceBranch\(""\)', "AssemblySourceBranch(@""$buildSourceBranch"")" } |
%{$_ -replace 'AssemblySourceChangeset\(0\)', "AssemblySourceChangeset($buildSourceVersion)" } |
%{$_ -replace 'AssemblyBuild\(""\)', "AssemblyBuild(@""$buildDefName / ID: $systDefinitionId / Version: $buildDefVersion"")" } |
Set-Content $file.FullName -Force
}
I am modifying the AssemblyProduct
attribute by writing into it the build definition name and the changeset which was used to create the binaries. Later on this info is visible on the properties of the exe or dll in Windows Explorer on the details tab.
Moreover I have defined the custom attributes AssemblySourceBranch
, AssemblySourceChangeset
and AssemblyBuild
to carry more detailed info. They all have the same structure, so for brevity only the source code of AssemblySourceChangeset
:
[AttributeUsage(AttributeTargets.Assembly, AllowMultiple = false)]
public class AssemblySourceChangesetAttribute : Attribute
{
public AssemblySourceChangesetAttribute(uint changeset)
{
Changeset = changeset;
}
public uint Changeset { get; }
}
Should the info in the "publicly" visible product field not be enough to be able to rebuild the binary, one can still result to reflecting upon the exe or dll and read those custom attributes which have info on the source branch, the id and the version of the build definiton stored.
来源:https://stackoverflow.com/questions/43147361/how-to-figure-out-the-changeset-a-tfs-2015-build-was-build-from