{"id":185,"date":"2017-06-05T09:00:08","date_gmt":"2017-06-05T13:00:08","guid":{"rendered":"http:\/\/langstonsoftware.com\/?p=185"},"modified":"2024-01-30T19:09:16","modified_gmt":"2024-01-31T00:09:16","slug":"automatic-versioning-of-csharp-mvc-applications","status":"publish","type":"post","link":"https:\/\/langstonsoftware.com\/2017\/06\/05\/automatic-versioning-of-csharp-mvc-applications\/","title":{"rendered":"Automatic Versioning of C# MVC Applications"},"content":{"rendered":"

I recently had a project that had me delving into the following blog post on assembly versioning: https:\/\/blogs.msdn.microsoft.com\/jjameson\/2009\/04\/03\/best-practices-for-net-assembly-versioning\/<\/a><\/p>\n

The blog post had a couple of problems. The first that came to mind was that the linked examples were using Team Foundation Server, while I was using Atlassian Bamboo. The second is that it seemed like a lot of work, especially when dealing with a large number of existing projects in a legacy solution all churning version numbers. Jumping back into Google I found a new blog post: https:\/\/blogs.msdn.microsoft.com\/jjameson\/2009\/04\/03\/shared-assembly-info-in-visual-studio-projects\/<\/a><\/p>\n

This seemed better, but I was not sure that putting all the assembly version information into one shared file is correct either. It seems like we’d be doing fine keeping our dlls at the default 1.0.0.0 version, I just wanted to tag the dlls with our Git commit SHA. Otherwise our repo would churn on build. Also, I’d prefer to do a full replace during my build on a file that only contains the information I want to change across my entire repo, leaving the rest alone. So I decided that modifying the AssemblyInformationalVersion in a CI script made the most sense for what I was trying to accomplish.<\/p>\n

I searched further and found the MSBuild Community Tasks<\/a> repo. However, I prefer PowerShell to MSBuild target XML “programming”.<\/p>\n

Example below is using Bamboo build environment variables, but can easily be tailored to your CI build system. For those who know Bamboo, you might notice the Bamboo variables look a little different in PowerShell<\/a>. For those new to Powershell, I’m using the backtick (`) as the string escape character.<\/p>\n

$revision = $Env:bamboo_planRepository_revision\r\n$buildNumber = $Env:bamboo_buildNumber\r\n$text = "$revision - $buildNumber"\r\n$text > 'Version.txt'\r\n\r\n$assemblyText = "using System.Reflection;`n[assembly: AssemblyInformationalVersion(`"$text`")]" \r\n\r\n$assemblyText > 'SharedAssemblyInfo.cs'<\/pre>\n
You can add the Version.txt file as an ignored route in MVC if you’d like it to be served by ASP.NET. I created two dummy files in the top of my repo that whose contents would be replaced by this script. I included these shared files in all the projects by linking to them<\/a>. I did move my dummy SharedAssemblyInfo.cs file into the Properties folder of my projects so it could sit side-by-side with the default AssemblyInfo.cs file. Now I can either look at Version.txt from a browser, or right click the dll directly on the machine to see the “Product Version” under the Details tab of the Properties modal.<\/p>\n","protected":false},"excerpt":{"rendered":"
I recently had a project that had me delving into the following blog post on assembly versioning: https:\/\/blogs.msdn.microsoft.com\/jjameson\/2009\/04\/03\/best-practices-for-net-assembly-versioning\/ The blog post had a couple of problems. The first that came to mind was that the linked examples were using Team Foundation Server, while I was using Atlassian Bamboo. The second is that it seemed like …<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"nf_dc_page":"","jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[12,20,2,19,18],"tags":[],"class_list":["post-185","post","type-post","status-publish","format-standard","hentry","category-asp-net-mvc","category-bamboo","category-c","category-continuous-integration","category-powershell"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p6Os38-2Z","_links":{"self":[{"href":"https:\/\/langstonsoftware.com\/wp-json\/wp\/v2\/posts\/185"}],"collection":[{"href":"https:\/\/langstonsoftware.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/langstonsoftware.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/langstonsoftware.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/langstonsoftware.com\/wp-json\/wp\/v2\/comments?post=185"}],"version-history":[{"count":5,"href":"https:\/\/langstonsoftware.com\/wp-json\/wp\/v2\/posts\/185\/revisions"}],"predecessor-version":[{"id":618,"href":"https:\/\/langstonsoftware.com\/wp-json\/wp\/v2\/posts\/185\/revisions\/618"}],"wp:attachment":[{"href":"https:\/\/langstonsoftware.com\/wp-json\/wp\/v2\/media?parent=185"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/langstonsoftware.com\/wp-json\/wp\/v2\/categories?post=185"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/langstonsoftware.com\/wp-json\/wp\/v2\/tags?post=185"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}