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)
Related
Xcode 11 has changed the way that versions are handled.
So far I had two targets, Dev & Prod, each with a separate versions. Prod version would be entirely manual, Dev would be automated:
During a build, a script would run, which then would fetch git tags. One tag would contain information about the latest Dev version. If it's newer, it would update version inside Info.plist just for the Dev target
When Dev would be deployed using a script (create an ipa, resign for in-house distribution, upload), the build version would then be increased. Remote tag containing version information would then be updated
In this way everyone's dev version would get automatically synchronized and managing multiple dev builds would be be easy. Prod would be updated relatively infrequently so it can be managed manually.
However, in Xcode 11 whenver version (or build) is updated inside the General tab, entries in Info.plist are replaced with $(CURRENT_PROJECT_VERSION) and $(MARKETING_VERSION) and Current Project Version and Marketing Version inside the build settings tab is used instead.
So far I would use PlistBuddy in order to read and update versions inside Info.plist, but from what understand now I'd have to use agvtool. However, there are two issues with it:
If it's ran as a Run Script phase, it causes the build process to cancel
It is unable to handle separate versions for two targets (so I cannot just automatically manage Dev, while leaving Prod alone)
I know that theoretically I can still use Info.plist for versioning, but the moment someone changes version manually in the General tab, the whole thing will get messed up (from experience I know that this will happen).
I have two questions:
Is my understanding of the process correct?
Can still have a version management system using agvtool similar to what I had before?
I'm new here.
I created a project and edited it few times. to back up I made a copy of the project folder. I see that in the Xcode 5 appears Source Control and I try to use it for my project versions back up. I selected from the menu: Source Control > Check Out - and entered a Repository Location => it created an empty project (with my project name). How can I save versions of a project?
I recommend not relying on xcode's built-in version control.
Try out http://github.com
For local use the building Git is good, commit often.
See, the Apple WWDC-13 session 414 (Understanding Source Control in Xcode) for more information.
For secure off-sit setup a remote repository, GitHub is the most popular but not free for private repos. Bitbucket is free for limited private repositories and is easy to use.
Just wondering on the recommended process of checking in an output of a project or solution post a successful build.
For example the Build relates to a common library. Post a change I want that to be checked in to a known location so other solutions can reference.
Some examples might be
Custom Workflow activities
Invoking TF exe directly
I would not check an output in. Instead, I would move it to a well-known location, probably a file share.
I don't do this currently but plan to investigate NuGet as a solution to this scenario. MSDN has some articles showing how to incorporate NuGet into your projects and host a private gallery of your own NuGet packages. MSDN has examples of a build that compiles your common code and then packages it and updates it into your private NuGet gallery. Then in your projects you would consume the NuGet package of the common library you wish to use.
Main MSDN article describing this:
http://msdn.microsoft.com/en-us/magazine/hh781026.aspx
Other resources:
http://nuget.org/
http://nugetter.codeplex.com/
Have a look at this post from Ewald Hofman, it updates certain files and checks them in using a custom activity. You could use the same process. But this involves customizing the build process template and deploying custom build activities to all build agents.
But you might also want to investigate the free AIT Dependency Manager which can download the latest specific version (can filter on build outcome or quality) of one build from the buildserver as reference to another build (also inside Visual Studio). This is a lot more flexible than constantly checking in the build output and allows you to have your dev branch to always get the latest (unstable) version, but your release branch to always get the latest well tested and approved version.
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.
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.