I am currently configuring my .NET 4.5 solution in the TFS Build 2010. I am working with Visual Studio.
I have a versioninfo.cs file as part of my solution. How can I set this up to increment the version number in it during the build process? What change do I need to make to my build definition for this?
What is versioninfo.cs in your implementation?
The way I typically do automatic versioning is to use the Community TFS Build Extensions TfsVersion activity: http://tfsbuildextensions.codeplex.com/wikipage?title=How%20to%20integrate%20the%20TfsVersion%20build%20activity&referringTitle=Documentation
I usually use the format: Major.Minor.YYMM.DDRR where Major/Minor are passed as arguments via the Build definition and manually incremented. YY/MM/DD/RR are the year-month-day-revision that allows me to know which specific build/source was used to create an assembly given it's version #.
If you have multiple branches/builds that you want to distinguish between based on the assembly version alone you may need to tweak your version numbering scheme slightly to include some kind of branch identifier.
Try this answer to Stack Overflow question Working automatic build increment Visual Studio addin.
This is a free independent stand-alone tool named ProjectBuildCounter which I hope is what you're looking for.
Related
Technologies:
Proget – Nuget Package management server
TFS – On premise 2017 Update 1
Issue:
When re-releasing a build from TFS release, to re-package a CI Nuget package that has already gone to my Proget development feed, there does not appear to be a way to get automatic Semantic versioning.
The help dialog that appears in regards to setting the version within the Nuget packager setup is as follows.
Use Date and Time If you choose 'Use the date and time', this will
generate a SemVer-compliant version formatted as X.Y.Z-ci-datetime
where you choose X, Y, and Z.
Use an Environment Variable If you choose 'Use an environment
variable', you must select an environment variable and ensure it
contains the version number you want to use.
Use the Build Number If you choose 'Use the build number', this will
use the build number to version you package. Note: Under General set
the build format to be
'$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)
I’d like to be able to re-release a Nuget package that has gone from my CI build in TFS to my Proget development feed, over into my production Proget feed. Microsoft has a great article on Versioning NuGet packages in a continuous delivery world. In that article they elude to the fact that they are doing something similar, but they aren’t providing any real direction for how it was accomplished.
Question:
How would you configure the Nuget packager so that upon creating the package you would input a build variable? Or is there a way that you could set the major version and just have the minor increment each time? How are others handling the promotion of packages from development to production?
Have tried the following:
Tried $(Version) as a build & release variable, and it doesn’t seem to work. The package gets tagged with the date. Also, this only seems to be really functional in the Build portion of TFS where the modal window contains a spot to modify this value.
Tried using the date & time method, and it sticks CI into the build number. This is almost exactly what we want minus the CI definition. Because it automatically inserts CI, this is not suitable for production.
Turned it off and it pulls the version from the Nuspec, but then this would assume that in your CI build you are always upping the version number to one more than current after you have pushed your last release version. This is because the nuspec is in the build files that you are re-releasing through the TFS release chain. Confusing to say the least.
Use the build number set to $(BuildDefinitionName)$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r) What I’d like here is $(Major).$(Minor).$(Patch). Trying $(Version)$ with a version of 1.0.0 gets you a file named with that has 2017.11.3.1 as the output, seemingly ignoring the $(Version) variable.
Not sure if I totally got your point, seems you would like to create a semantically versioned nupkg after ci process on TFS.
Usually the nupkg should be as shown MSVersioningSample: 1.0.8-ci-20171106-156033.nupkg
However you would like to rename nupgk and republish it to nuget server as the release version simply MSVersioningSample: 1.0.8.nupkg The same as $(Major).$(Minor).$(Patch).
You need to edit NuGetPackager.ps1 in the build agent, change the $VersionRegex value, details you could have a look at the answer in this question: How do I get TFS 2015 to parse 3 digit versioning for NuGet packaging
Also give a try with some 3-rd party extension to handle with Semantic Versioning in TFS build, release task, nuget package, a sample for your reference: Semantic Versioning Build and Release Tasks
Besides just a note: Semantic Versioning 2.0.0 is only supports with NuGet 4.3.0+ and Visual Studio 2017 version 15.3+.
I know that the AssemblyInfo class can be set to auto increment the build number as such:
[assembly: AssemblyVersion("1.0.*")]
But this works only for building the app myself (i.e. from the IDE). I use TFS to build my solution (multiple projects). The assemblies in the build drop location are all still set to version 1.0.0.0.
What is the path of least resistance for getting the build or revision number into the AssemblyVersion?
Ideally, TFS already has a $(BuildID), an auto-incrementing integer, that I use as my Build Number Format for defining my drop location...can't that just become the version build number in the AssemblyVersion and AssemblyFileVersion?
Well, gave up on native TFS. This was the closest to a configuration-only solution (no coding). The documentation on this site shows clearly how to modify your TFS server and build to use this dll to get an incrementing number in your assembly's product and file build and rev (it's a Julian date and rev).
http://tfsversioning.codeplex.com/
I think creating your own custom build activity to update the version number is the easiest way to achieve this. Here is a good post on that:
http://www.ewaldhofman.nl/post/2010/05/13/Customize-Team-Build-2010-e28093-Part-5-Increase-AssemblyVersion.aspx
I've been tasked with setting up a new Team Foundation/Build server at my company, with which we'll be starting a new project. Nobody here currently has experience with TFS, so I'm learning all of this on my own. Everything is working so far; The server's been set up, the Repository and Team Project has been created, the Build Server has been created, and I've created a simple hello world application to verify the source control and Continuous Integration builds (on the build server) run properly.
However, I'm having a problem setting up the automatic versioning. I've installed the TfsVersioning project, and it's working fine; I'm able to define a format for my assembly versions. I haven't yet decided what format I'll use; probably something like Major.Minor.Changeset.Revision (I'm aware of the potential problem regarding using the changeset number in the assembly version, so I may decide to switch to Major.Minor.Julian.Revision before we begin development).
The problem:
I don't want assemblies to have new file versions if their source code has NOT changed since the last build. With a continuous Integration build this isn't a problem, as the build server will only grab the source files that have changed, causing an incremental build which produces only updated modules; the existing unchanged modules won't be built, so their version will remain unchanged.
If I set up a nightly build, I'll want to clean the workspace and perform a Build-All. However, this means that ALL assemblies will have new version (assuming the Assembly File Version includes the build number).
A solution?
This has prompted me to consider using the latest changeset number in the Assembly File Version. This way, if nothing has been committed between two successive Build-Alls, the versions won't be incremented. However, this would mean that a change and commit to a single file would force a version increment on ALL assemblies.
I'm looking for one of two things:
A way to only increment Assembly Version Numbers if their source/dependencies have changed since the last build. Successive Build-Alls should not cause changes in version numbers.
OR
A way for testers and non-developers to be able to tell version W.X.Y.Z and version W.X.Y.Z+1 of assembly 'Foo' are identical, even though they have differing file versions.
I've probably read about 20 articles on the subject, and nobody (except this guy) seem to address the issue. If what I'm asking for isn't common practice in the Team Foundation ALM, how do I address the second bullet point above?
Thanks for your time!
This is something I did in the past. The solution has two critical points:
You must use an incremental build, i.e. Clean Workspace = None
The change to AssemblyInfo.cs must be computed at each project
This latter is the most complex and I will just draft the solution here.
In the custom MSBuild properties use CustomAfterMicrosoftCommonTargets to inject an hook in normal Visual Studio compile
/property:CustomAfterMicrosoftCommonTargets=custom.proj
Also forward a value for the version
/property:BuildNumber=1.2.3.4
In custom.proj redefine the target BeforeCompile to something similar
<Target Name="BeforeCompile"
Inputs="$(MSBuildAllProjects);
#(Compile);
#(_CoreCompileResourceInputs);
$(ApplicationIcon);
$(AssemblyOriginatorKeyFile);
#(ReferencePath);
#(CompiledLicenseFile);
#(EmbeddedDocumentation);
$(Win32Resource);
$(Win32Manifest);
#(CustomAdditionalCompileInputs)"
Outputs="#(DocFileItem);
#(IntermediateAssembly);
#(_DebugSymbolsIntermediatePath);
$(NonExistentFile);
#(CustomAdditionalCompileOutputs)"
Condition="'$(BuildNumber)'!=''">
<Message Text="*TRACE* BuildNumber: $(BuildNumber)"/>
<MyTasksThatReplaceAssemblyVersion
BuildNumber="$(BuildNumber)"
File="$(MSBuildProjectDirectory)\Properties\AssemblyInfo.cs"/>
</Target>
You need to have a task for replacing the AssemblyFileVersion in the AssemblyInfo.cs source. MSBuild Extension Pack has an AssemblyInfo task for this purpose.
I posted the full details at my blog here, here and here.
Pls see screenshot. I have setup continuos integration with tfsservice.
It builds and deploys after each checkin.
I would like to append or pre-pend if that word exists, the assembly version so that I can easy recognize what build generated what version, and I can easy identify in which build a bug appeared.
If you mean you need to get the version number from a library during the build, then you can use the Assembly class in the MSBuild Extensions Pack to get the version number from the desired library.
This is feasible, but you need to customize your build template.
A good starting point is the Visual Studio ALM Rangers' BRDLite Reference Templates. See Assembly Versioning example in the BRDLite.Asp.NetTemplate.2012.2.xaml template.
We're using Team Foundation Service instead of a local TFS.
Our solution was created on Visual Studio 2012.
My problem is now that we want all assemblies to have the same version number (this part is already solved by using a CommonAssemblyInfo.cs that is linked into all projects).
The issue I'm facing right now is that we need the tfs changeset number at the last digit of the assembly version (e.g. 1.0.0.4711 where 4711 is the changeset number).
I've found several examples, but none of them worked for me.
And yes, I especially searched here on stackoverflow a lot.
I also have to admit that I've never looked into the MSBuild scripts...
Can anyone please give me a hint on how to accomplish this?
Is it for example possible to use the MSBuild Extension Pack on Team Foundation Service (not local TFS) and if, how to do that?
As always, time is my worst enemy...
Note that from 2010 Tfs employs Windows workflow for building the package the workflow calls msbuild for compiling the projects only - while its possible to pass changeset this way to msbuild its rather more hops.
Following deals with your problem, however the linked solution is more complex that needed:
Can assembly version been automatically updated with each TFS 2010 Build?
This is one of best series of tutorials on the custom build activities, the author is on stack as well i believe, one specificly about versioning
http://www.ewaldhofman.nl/post/2010/05/13/Customize-Team-Build-2010-e28093-Part-5-Increase-AssemblyVersion.aspx
In short you need a custom activity to run before compilation on source files, find all CommonAssemblyInfo.cs files, feed this list to your custom activity, it modifies the values inside with passed value of full version number or only the changeset and optionaly check in the change (probably not since your changeset will be out of sync then).
You can also take a look at https://tfsbuildextensions.codeplex.com/ set of activities there is TfsVersion activity among them, at the very least it will provide examples.
Functionality need for this should be available through Team Explorer and source control - The Custom activity assemblies and build templates usually are located in folder in your team project root - the location of this folder is defined for build controller you can change this through team explorer build section.
Changeset is available from value BuildDetail.SourceGetVersion, not sure if this was fixed/changed in 2012 however there were 2 issues about this value in 2010
Its doesnt respect GetVersion override in default build template - you will manualy need to update if override is used
When running latest build (no override) it will get the last changeset number from tfs - depending on your branches this may not be the same as 'last' changeset for the branch of build. You will either have to live with this, provide overrides for each build or implement activity that checks branch history for last changeset value and overrides it again.
It should be noted that GetVersion should be able to accept any sourcespec version - changeset, date, label etc. I havent played around with this enough to provide more details to you.
Colin Dembovsky wrote a great overview of doing version embedding using the new pre-build script setting in TFS 2013 build definitions.
The Changeset number is easily accessible within the pre-build process in the environment variable TF_BUILD_SOURCEGETVERSION. I was able to use this to embed the Changeset value in our binaries using a script based on Dembovsky's work above. (I used Perl, not powershell, so you probably don't want to see it ;-)
This approach doesn't require any changes to the build workflow which makes it a big win for me.
I've used Wintellect's solution - MSBuild-only, no TFS magic needed. I also added to the auto-generated CSharp file:
[assembly:AssemblyInformationalVersion("$(BuildNumber)")]
So I get the TFS build number.