I'd like to use the current Subversion revision number in my AssemblyFileVersion attribute to have this in the final complied dll.
I've used the MsBuild Community Task library from my deploy script to read the revision number and update the AssemblyInfo - this somewhat works, but ...
When I have an updated project and a current revsion number, say for example 100. I run the script and that will update the AssemblyInfo and a final dll with 100 as an attribute. When I then check these new AssemblyInfo files in I'll get a new revsion number (101).
The problem then is that if I see a dll with a specific revsion number and like to rebuild that dll the actual revsion I need is actually the one after the revsion numnber I see ...
How can this process be improved?
Is it possible to use RCS Keywords?
One of the keywords is $Revision$. This expands automatically to $Revision:xxx$ where xxx is the Subversion revision number every time you do a svn checkout or svn update.
You'll have to set the property svn:keywords on your Assembly file in order for this to work:
$ svn propset svn:keywords Revision Assembly.cs
I do this all the time, but for the build server that runs our continuous build software. That's takes a bit of setting up, but it will automatically build the software, set the correct version number, and even deploy the software every time someone does a commit.
By the way, I take it you're using AnkhSVN as your Subversion integration for VisualStudio.
Related
So i've build an AwesomeApplication.exe with visual studio winforms,
it has a public repository with releases.
I'd like to add update checker to the application (notifying the user that new release is available for download).
I can get latest release info with github api:
https://developer.github.com/v3/repos/releases/#get-the-latest-release
But the application doesn't "know" which github release tag or version it is,
unless i'd manually type that in the application settings (before building it)? and then using the api, compare that hard coded version string with github release tag. That would be possible, but requires bit too much manual work.. wondering that are there other options?
my publish process is:
build app in visual studio
manually zip the exe
manually add release and upload zip to the repository
Solution, modified version of #VonC link:
Add visual studio prebuild event to fetch current latest release tag (my prebuild script that launches powershell to access github api: https://gist.github.com/unitycoder/c4c5330ad3494ee5b2344a0a86324a3d )
The fetched tag is saved in the project folder as PreviousVersion.txt, which is set as a EmbeddedResource in the project (with CopyToOutput set to "Do Not Copy", as i didnt want extra files to the folder)
When user clicks "Check Updates" button in the application, ill read the embedded PreviousVersion.txt and compare it with currently available github release tag using https://developer.github.com/v3/repos/releases/#get-the-latest-release
If the strings are different, that means user must be using older version
Small update on that:
Actually with that checkup above, the string would be always different, since at compile time the current latest release is, lets say 1.10, while after compile and adding new release, its already 1.11 (and compile time string is the old 1.10).
So temporary fix for that is to float or int parse your version tag number,
compare if its larger by 0.1 or 1 for example, then show update available.
You can embed the current version in your exe: see "Embed git commit hash in a .Net dll".
That way, your Application can compare its internal version (based on git describe --long, which includes the closest tag) with the version from the latest release (which is based on a tag as well)
I have set up my TeamCity 10.0.3 to create an assembly version number during the project build that uses the build.vcs.number (which corresponds to the changset number on the VCS Root - taken from Plastic SCM) as one of the parts.
The format is similar to this; {major}.{Minor}.{build.vcs.number}.{build counter}
This method has worked perfectly for quite some time returning the changset number (and only the number) from my VCS system.
The Plastic plugin for TeamCity has now been upgraded to the latest version (SNAPSHOT-201611231807) and since the upgrade after the VCS Root has been created the build will successfully return the changeset number that can be used within the assembly version number.
The error occurs as soon as anyone checks something into the monitored branch - at this point if an automatic or manual build is triggered the information returned as build.vcs.number has lots of additional information that breaks the build.
An example of what is returned after a checkin is:
cs.418 (guid:6a2d5c45-b1b8-4f03-889c-3f3c80c6e209)
This appears to be both the changeset number along with the ID of the changset.
If I re-create the VCS root from scratch the correct number will be returned - until something is checked back in.
How can I resolve this error as all I want returned is the changset number
many thanks in advance
We have just released a new Teamcity plugin version including new features and a big code refactor. We are aware of this problem and we are going to configure the "build.vcs.number" variable to always show the changeset number (as we do in previous versions of the plugin). The task should be done very soon.
Please contact us at support at codicesoftware dot com if you need more information.
We'd like to increment the minor version of our application each time we create a new branch for release. So if, for example, the current version is 4.17 the next branch we create would automatically increment the version number to 4.18.
Our scheme is that the code follows the following path:
Dev -> Test -> Staging
so that the testing happens on code we think has the functionality required and only that code that passes testing is available for release.
Then when the time comes for a new release we take a new branch of Staging, so we have the following structure:
Staging
|----> Release 4.1
|----> Release 4.2
...
|----> Release 4.17
There is no cross pollination between the release branches.
So what we need is something that will increment the minor version number when a new branch is taken. We can reset the version number of the application in Dev/Test/Staging to anything that needed for this to work.
Is this possible with TFS/VS 2013 out of the box?
That is a bad smell!
You have to do that on one branch, and no in all... And not change the assembly number in a manual way...
The TFS Versioning could help you to do this.
In the community build tools you will find an activity called TFS Version. This tool can, in its default configuration, strip the version number from the build name. If you name your build for the branch to be mybuild_7.8.0$(.r) the tool can be configured to pick up that version and store it in a variable. You can then use that variable to update the AsemblyInfo.* file versions.
This is the correct way to do what you are asking. Do not check the changes in, and indeed set the checked in numbers to be 0.0.0.0. This way you will be able to identify when a cheeky developer has done a local push and when it came from a build server 😃
https://tfsbuildextensions.codeplex.com/wikipage?title=How%20to%20integrate%20the%20TfsVersion%20build%20activity&referringTitle=Documentation
We have a couple of projects configured in cc.net. Each of these projects has following items in it's working directory (svn):
source
lib
db scripts
SSIS package(s)
We would like to know if there is a way to find out if there are any modifications in the subdirectory containing the SSIS packages? This would allow us to do a full build (including execution of package). We don't want to do this with every build since package execution might take some time...
Our other option is to create a cc.net project that does the complete builds at night time.
Does anybody have a nice solution to this problem?
I would use the SvnVersion task from MSBuild Community Tasks to identify the latest revision on the SSIS package subdirectory. Then compare it to one you've stored in a file somewhere in your working directory or elsewhere.
If it's different, pass a property to your main MSBuild task with a flag instructing to build and execute the SSIS packages. Once that's done, update your revision file with the new new revision number for the SSIS subdir.
I'm trying to setup my VisualStudio project to set the assembly version based on the latest subversion revision number as described on this page. But the version number always seems to lag one revision.
I've split out the assembly version attribute into a separate file, VersionInfo.cs, that is updated with a pre build event.
I'm using the following code to display the version number in the title of my form:
System.Reflection.Assembly assem = System.Reflection.Assembly.GetExecutingAssembly();
this.Text = "My Program Version: " + assem.GetName().Version.ToString();
Here's an walk through of what's happening.
I commit my project so that it is at the latest revision.
Using TortiseSVN I use show log to see that I'm at revision 55
I build my solution.
I then open VersionInfo.cs and see that the pre-build event correctly overwrote this file as
[assembly: System.Reflection.AssemblyVersion("0.1.55.*")]
Yet when I run the program the title bar displays and old version 0.1.52.20486
Next I open the project file in notepad, and change something, such as adding a blank line, and then save the file.
VisualStudio shows a notification that the project file has changed and prompts me to reload the project which I accept
Now when I build and run the program the form shows version 0.1.55.20645
I make a change to something in the project, and commit to SubVersion.
TortiseSVN confirms my working copy is now at revision 56.
I build my project and VersionInfo.cs is correctly updated to
[assembly: System.Reflection.AssemblyVersion("0.1.56.*")]
I try running the application again and the forms title shows 0.1.55.20750 rather then 0.1.56.xxxxxx
Also I've noticed that even if I rebuild/rerun my application the build number (the last number in the version number) is also not updated. It was my understanding that the asterisk would be replaced my a new number at each build.
Any one have any idea what's going on?
I haven't worked with the specific tool you are using but the tool I am using requires you to do an update on your sandbox after your commit. Has something to do with the tool using the revision number retrieved by the last update, not the last commit.
When you checkin a file, the revision number is incremented as you know. The problem is, you do not know what that revision number will be when you checkin - you only find out after checkin.
So, if you take the latest revision number, build your project, then checkin - the number used will always be out of date. What you really want is to be able to checkin, then get the revnum of the commit you've just performed, and then build your project with the correct version number.
Obviously this is not possible.
There is a way round it - use a CI system that builds your project immediately after checkin (through a post-commit hook). These will checkout the latest version you've just added, update your version.cs file, then build. The disadvantage is that your version.cs file will never contain the correct version number (unless the CI system then checks just it in again)
The best way to handle this is when you do your build.
I use Jenkins as my continuous build server instead of relying on doing a manual build on my system. If you don't use something like Jenkins (Hudson, Atlassian Bamboo and CruiseControl are three other popular Continuous Build servers), you should. This way, your official builds are not dependent upon a particular developer machine.
If you do use Jenkins, you can now use Nant or even Ant to help you manipulate your build. We are doing this now with Jenkins and Ant.
What I do is use msbuild.exe to build my project using Jenkins. Before I do a build, I use Ant to retrieve the Subversion revision number (actually, we use Jenkin's build number, but the theory is the same) to modify the assembly file with the correct version. Then, I do a build itself. The results is the correct Subversion revision number (err.. in our case the Jenkins Build Number) in the assembly file when it's built.
Come to think of it, you can probably do what you're doing now to set the Revision in the Assembly file. Jenkins will then build the project with the correct Revision number in the assembly file. You download the built package, and you'll see the correct version number in the title bar.