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.
Related
I updated to Visual Studio 2015 when it was released last week. Resharper suggested that I might like to update the following string using string.Format:
string filePath = HttpContext.Server.MapPath(string.Format("~/App_Data/{0}.xlsx", Guid.NewGuid()));
To use string interpolation:
string filePath = HttpContext.Server.MapPath($"~/App_Data/{Guid.NewGuid()}.xlsx");
I did this, and all is well.
However I've broken the build on TFS:
Controllers\MyController.cs (224):
Unexpected character '$'
So it seems like the new features in C# 6 can't be compiled by our older, non-updated version of TFS.
The project is still targeted at using the Framework 4.5 however, I have not targeted 4.6. I (wrongly) assumed that still targeting the old framework would mean it could be built by other team members still using VS2013 along with our TFS build server.
So it looks like our TFS needs an update of... something.
What do I need to install on the TFS server to have it compile this new syntax? The latest version of the .NET Framework or something else?
Install .NET Framework 4.6 and Build Tools 2015 on your build server.
Then override the ToolsVersion (/tv:14.0) in MSBuild arguments.
Unfortunately, there doesn't appear to be an easy way to get older versions of TFS working with C# 6.0 without installing VS2015 on the TFS build server. If you can do that, I would suggest that. If, for whatever reason, you cannot, then the following worked for me:
I followed the instructions of the other answer, but that alone didn't work. I also had to edit the default TFS build process template (which in my case is found in $//BuildProcessTemplates) and change the ToolPath properties of the "Run MSBuild for Project" nodes to the location of MSBuild 14.0 (which usually is C:\Program Files (x86)\MSBuild\14.0\Bin).
You will then need to update your build definitions to use the new build template (if you had copy/edited a new one vs editing the original one).
At this point, you should be able to build C# 6 projects with TFS, but if you're trying to do web deployment/packaging as well, then there are still a few more steps.
On the build server, at C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0, there should be a Typescript folder and nothing else. On your local machine with VS2015, go to the same path. There should be a Web and WebApplications folder. Copy those over to the server's folder. You should now be able to package/deploy web projects as well.
Please check to see if "Run MSBuild for Project" exists more than once within your TFS Build process template. In my case it existed twice and took me awhile to figure out why the change for ToolPath was not taking the desired effect.
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.
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.
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.