Versioning in .NET projects and not only
In the methodology for changing product versions for me for a long time there were incomprehensible moments, because there are too many different ways to change the version when making changes to the product. The strategies I came across are using four numbers in the version number (for example 1.5.2.871).
The first three are always changed manually, and usually do not exceed 10, and the last - manually or automatically, and means the build number. It was especially incomprehensible to me how to assign version numbers to product components if the Visual Studio solution and the product structure included not one executable project, but several projects (maybe 10 or more) of various types (executable modules and libraries).
For myself, I came up with a solution that suits me perfectly, if interested,
In particular, in .NET projects, the AssemblyInfo.cs file is created by default, in which the following code is present by default:
Maybe I didn’t figure it out to the end, but I couldn’t get the mechanism with AssemblyVersion (“1.0. *”) To work more or less intelligently. I also did not find any clear descriptions in MSDN. Therefore, I decided to think about my own solution, which works well with Subversion now.
When releasing product versions, it is often necessary to manually change the first three digits of a version. We increase the first digit (major) - very significant changes, maybe even the kernel has been rewritten or some parts of it. Second digit (minor) - new functionality added, possibly relatively small. The third digit - bugs fixed, plus minor improvements, added functionality. But for testing and identifying builds, this is not enough when working with testers. If you constantly name the distribution as “MyProductSetup_1.3.7" and submit it for testing, working with issue tracker - identifying the build in which the problem manifests itself is quite difficult. That is, you need to increment the last digit in the version number. Doing it manually when there are many projects in solution for each new build is a very tedious job.
Therefore, I decided to use automatic assembly with automatic version increment. I’ll describe it without implementation details (of course I can add it if necessary), I’ll just say that I wrote a small script for MS Build and MS Build Community Tasks, .NET developers are familiar with these tools.
So, the current version of the product, from 3 digits, is stored in SVN in a plain text file (I store it in XML), and is changed manually by the product developers, because product version changes are usually followed by releases, release notes, user notifications, site updates, etc.
The assembly in steps performed by the script:
1. Do SvnCheckout
2. Change the versions in AssemblyInfo.cs in all projects to the current version + revision number of the corresponding branch of the project. For example, if the current version of the product is 1.3.2, and the SVN revision of the MySoundLibrary project branch is 286, set the version to AssemblyInfo 1.3.2.286.
3. For the distribution (I have InnoSetup), we expose the SVN version of the entire solution (the directory where the .sln file is stored)
4. We build, name the resulting .exe (.msi) file as MyProduct_v_1_3_2_286.exe
5. Commit the changes. Important: the branches of all projects in the solution are commit separately.
As a result, we get:
- One-button
build / file launch (can be hung, for example, on CruiseControl.NET) - Each distribution build reflects the state of the SVN repository in the last digit of the file name
- All components of the build (.dll, .exe) reflect the state of the corresponding SVN branches of the project. Those. looking, for example, on the version of a .dll file, you can find out from which revision it was built. It is also convenient to track changes: the larger the latest version of the .dll file, the more actively it changes.
Maybe I’ve stated it too chaotically, I tried only to propose a method, not an implementation, I hope that I did not invent the wheel :)
The first three are always changed manually, and usually do not exceed 10, and the last - manually or automatically, and means the build number. It was especially incomprehensible to me how to assign version numbers to product components if the Visual Studio solution and the product structure included not one executable project, but several projects (maybe 10 or more) of various types (executable modules and libraries).
For myself, I came up with a solution that suits me perfectly, if interested,
In particular, in .NET projects, the AssemblyInfo.cs file is created by default, in which the following code is present by default:
// Version information for an assembly consists of the following four values:
//
// Major Version
// Minor Version
// build number
// Revision
//
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
// [assembly: AssemblyVersion ("1.0. *")]
[assembly: AssemblyVersion ("1.0.0.0")]
[assembly: AssemblyFileVersion ("1.0.0.0")]
Maybe I didn’t figure it out to the end, but I couldn’t get the mechanism with AssemblyVersion (“1.0. *”) To work more or less intelligently. I also did not find any clear descriptions in MSDN. Therefore, I decided to think about my own solution, which works well with Subversion now.
When releasing product versions, it is often necessary to manually change the first three digits of a version. We increase the first digit (major) - very significant changes, maybe even the kernel has been rewritten or some parts of it. Second digit (minor) - new functionality added, possibly relatively small. The third digit - bugs fixed, plus minor improvements, added functionality. But for testing and identifying builds, this is not enough when working with testers. If you constantly name the distribution as “MyProductSetup_1.3.7" and submit it for testing, working with issue tracker - identifying the build in which the problem manifests itself is quite difficult. That is, you need to increment the last digit in the version number. Doing it manually when there are many projects in solution for each new build is a very tedious job.
Therefore, I decided to use automatic assembly with automatic version increment. I’ll describe it without implementation details (of course I can add it if necessary), I’ll just say that I wrote a small script for MS Build and MS Build Community Tasks, .NET developers are familiar with these tools.
So, the current version of the product, from 3 digits, is stored in SVN in a plain text file (I store it in XML), and is changed manually by the product developers, because product version changes are usually followed by releases, release notes, user notifications, site updates, etc.
The assembly in steps performed by the script:
1. Do SvnCheckout
2. Change the versions in AssemblyInfo.cs in all projects to the current version + revision number of the corresponding branch of the project. For example, if the current version of the product is 1.3.2, and the SVN revision of the MySoundLibrary project branch is 286, set the version to AssemblyInfo 1.3.2.286.
3. For the distribution (I have InnoSetup), we expose the SVN version of the entire solution (the directory where the .sln file is stored)
4. We build, name the resulting .exe (.msi) file as MyProduct_v_1_3_2_286.exe
5. Commit the changes. Important: the branches of all projects in the solution are commit separately.
As a result, we get:
- One-button
build / file launch (can be hung, for example, on CruiseControl.NET) - Each distribution build reflects the state of the SVN repository in the last digit of the file name
- All components of the build (.dll, .exe) reflect the state of the corresponding SVN branches of the project. Those. looking, for example, on the version of a .dll file, you can find out from which revision it was built. It is also convenient to track changes: the larger the latest version of the .dll file, the more actively it changes.
Maybe I’ve stated it too chaotically, I tried only to propose a method, not an implementation, I hope that I did not invent the wheel :)