Versioning in .NET projects and not only
The methodology of changing product versions for me for a long time remained incomprehensible moments, because too many different ways to change a version when you make changes to a product. The strategies I've come 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 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 products contain 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, if you're interested,
')
In particular, in .NET projects, by default, the AssemblyInfo.cs file is created, in which the following code is present by default:
Maybe I didn’t fully figure it out, but it didn’t work out to make the mechanism with AssemblyVersion (“1.0. *”) Work more or less intelligibly. I did not find any clear descriptions in MSDN either. Therefore, I decided to think over my own solution, which works well for me now with Subversion.
When releasing product versions, it is often necessary to manually change the first three digits of the version. We increase the first digit (major) - very significant changes, it is even possible to rewrite the kernel or some parts of it. The second digit (minor) - added new functionality, perhaps relatively small. The third figure - fixed bugs, plus minor improvements, adding functionality. But for testing and identifying builds, this is not enough when working with testers. If you constantly call the distribution as “MyProductSetup_1.3.7” and give it to testing, working with the issue tracker - to identify the build in which the problem manifests itself is quite difficult. Ie you need to increment the last digit in the version number. Doing it manually in the presence of many projects in a solution with each new build is a very tedious job.
So I decided to use an automatic build with an automatic increment of versions. I will describe here 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 well aware of these tools.
So, the current version of the product, from 3 digits, is stored in the SVN in plain text file (I store in XML), and is changed manually by the developers of the product, since a product version change is usually followed by a release, release notes, user notifications, site updates, etc.
Step-by-step build by script:
1. Making SvnCheckout
2. Change the versions in AssemblyInfo.cs in all projects to the current version + revision number of the corresponding project branch. 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 this InnoSetup), we expose the SVN version of the entire solution (the directory where the .sln file is stored)
4. We perform the assembly, call the resulting .exe (.msi) file as MyProduct_v_1_3_2_286.exe
5. Commit the change. Important: branches of all projects in a solution are committed separately.
As a result, we obtain:
- Build "one button" / running the file (you can hang, for example, on CruiseControl.NET)
- Each build of the distribution kit reflects the state of the SVN repository in the last digit of the file name
- All build components (.dll, .exe) reflect the state of the corresponding SVN project branches. Those. looking, for example, on the version of the .dll file you can find out from which revision it was assembled. It is also convenient to track changes: the larger the latest version of the .dll file, the more actively it changed.
It may be too messy, 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 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 products contain 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, if you're interested,
')
In particular, in .NET projects, by default, the AssemblyInfo.cs file is created, 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 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 fully figure it out, but it didn’t work out to make the mechanism with AssemblyVersion (“1.0. *”) Work more or less intelligibly. I did not find any clear descriptions in MSDN either. Therefore, I decided to think over my own solution, which works well for me now with Subversion.
When releasing product versions, it is often necessary to manually change the first three digits of the version. We increase the first digit (major) - very significant changes, it is even possible to rewrite the kernel or some parts of it. The second digit (minor) - added new functionality, perhaps relatively small. The third figure - fixed bugs, plus minor improvements, adding functionality. But for testing and identifying builds, this is not enough when working with testers. If you constantly call the distribution as “MyProductSetup_1.3.7” and give it to testing, working with the issue tracker - to identify the build in which the problem manifests itself is quite difficult. Ie you need to increment the last digit in the version number. Doing it manually in the presence of many projects in a solution with each new build is a very tedious job.
So I decided to use an automatic build with an automatic increment of versions. I will describe here 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 well aware of these tools.
So, the current version of the product, from 3 digits, is stored in the SVN in plain text file (I store in XML), and is changed manually by the developers of the product, since a product version change is usually followed by a release, release notes, user notifications, site updates, etc.
Step-by-step build by script:
1. Making SvnCheckout
2. Change the versions in AssemblyInfo.cs in all projects to the current version + revision number of the corresponding project branch. 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 this InnoSetup), we expose the SVN version of the entire solution (the directory where the .sln file is stored)
4. We perform the assembly, call the resulting .exe (.msi) file as MyProduct_v_1_3_2_286.exe
5. Commit the change. Important: branches of all projects in a solution are committed separately.
As a result, we obtain:
- Build "one button" / running the file (you can hang, for example, on CruiseControl.NET)
- Each build of the distribution kit reflects the state of the SVN repository in the last digit of the file name
- All build components (.dll, .exe) reflect the state of the corresponding SVN project branches. Those. looking, for example, on the version of the .dll file you can find out from which revision it was assembled. It is also convenient to track changes: the larger the latest version of the .dll file, the more actively it changed.
It may be too messy, I tried only to propose a method, not an implementation, I hope that I did not invent the wheel :)
Source: https://habr.com/ru/post/78813/
All Articles