One of the more annoying quirks with dealing with SharePoint is that once you develop a solution that requires custom code, all dependencies are then tied to the Strong Name of the compiled DLL. That strong name also includes the version number, usually 220.127.116.11, and cannot be changed without breaking all existing references. This is a good thing from a compatibility perspective but it does make it rather complicated to figure out exactly which version of a DLL is in use.
You can open up the WSP and then use the timestamps and take a guess at the version but it is not always reliable. One popular option is to manually set the AssemblyFileVersion attribute in the AssemblyInfo.cs file which then lets you simply right-click and view the DLL properties to see the information. Changing the AssemblyFileVersion does not impact the strong name of a library. This works well but requires that you remember to actually do it and it becomes very tedious if you want to do this for each build.
Instead, I created a solution that uses PowerShell combined with Visual Studio’s Pre-Build event command line to automatically update the AssemblyFileVersion for each and every build. It even will check the file out of TFS for you. The original concepts came from this post but I have made extensive modifications and added functionality.
Once that is in place you will need to update the ‘Pre-build event command line’ in the Project Properties in Visual Studio to be what is below:
%WINDIR%\SysNative\WindowsPowerShell\v1.0\powershell.exe "D:\PSScripts\IncrementAssemblyFileVersion.ps1 '$(ProjectDir)'"
The path to the specific version of PowerShell is important because Visual Studio is still a 32-bit application and having it attempt to call the default 64-bit version of PowerShell does not work. Also, I keep all of my scripts under a common folder (/PSScripts) just for the sake of management so you’ll want to point that at your script instead.
What this script can do :
- Automatically check the file out of TFS (naturally, if you dont use TFS or use a different mechanism, you will need to fiddle with the CheckOutFile() function
- The version number can be any content that you can create in Powershell. Dates, times, ticks, whatever. If you want to add some code, you can even read/write the info from external files.
- Specifying the word ‘increment’ for one of the version values (major, minor, build, rev) will take whatever value it finds there and will simply increment it by 1
- Specifying $null for one of the version values tells the script to leave whatever value it finds there
- As it is current implemented, it will only modify the Build and Revision part of the version number, using the Year and Month for the Build and an increment for the Build. Using the Time instead of an increment would have been useful as well but just seemed clunky. However, this can be done easily by updating the $build and $rev variables to the values desired.
I use this approach to update the AssemblyFileVersion but the code could very easily be modified to update any other property in that file.