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.
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.
I am currently implementing (I do not know if implementing is the appropriate word, but anyway) a semantic versioning in TeamCity. I have project level system parameters in which I store version number parts: system.major, system.minor, and system.patch. I have two build configurations:
First, we call it beta, is using the major, minor, and patch as-is and appends its build counter value to the version (i.e 1.0.0.X where X is beta's build count).
Second, we call it release, is using the major, and minor (but not patch) as-is and appends its build counter value as patch number (i.e 1.0.Y where Y is release's build count).
We want our versions to increment like following:
A beta build is run: 1.0.0.1
Another beta build: 1.0.0.2
A release build is run: 1.0.1.0
Yet another beta build: 1.0.1.3
The problem is, we want to use the release build's counter as patch number in beta build as well, without any human intervention. So far, I have read about people using assembly info or external VCS-tracked file to store the current version in last build step and parse the file in the first build step of every build configuration. This approach, though appears to be the standard way, is not welcomed by the project's manager, so I want to avoid using assembly info or another VCS-tracked file to store the version info. I have tried to use a powershell script build step in release configuration to set the parameter patch using:
Write-Host "##teamcity[setParameter name='system.patch' value='%build.counter%']"
yet, using teamcity[setParameter...] appears to take effect inside the running build and only on consecutive build steps. What I want is to set the system parameters in one build (release) and later, use their value in another build configuration (beta).
Is there any straight-forward way that I fail to see? If you have similar experience, can you point me to the right direction?
I am accomplishing something similar by doing an API call in a build step through powershell. Could this work for you? Do a GET request to find the current release build counter and then update the appropriate parameter with a PUT request.
I want to make the builds on a specific branch advance the version number in AssemblyInfo.cs files and in Package.nuspec files according to the Semantic Versioning convention (*).
In order to do this, when code is merged into this specific branch, I want to:
Ask the merging user for a new version number, preferably during merge (then run build during check-in) or when the user runs a manual build, preferably displaying a custom dialog which displays current version number and asks if API has been broken, expanded or if changes do not affect API, then save the new version number aside.
Apply version number to AssemblyInfo.cs file(s). (Related link)
Apply version number to Package.nuspec file(s).
Run build.
Publish resulting NuGet packages.
I am not sure how to get the first step working, as it is interactive.
Has anyone tried such as approach before?
Are there any known solutions?
Any tips how to solve this?
(*) Semantic Versioning convention:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
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.