Join Ted Neward for an in-depth discussion in this video Assembly version attributes, part of CLR Assemblies Deployment for .NET Developers.
- [Instructor] One of the first things that you'll start to play around with when you start working with assemblies, will be the Assembly Version Number. For what are fairly obvious reasons, as you work on your code, you will want ways to be able to differentiate today's assembly versus the one you built yesterday. And again, the assembly version is a four-part tuple. Major, minor and then two additional values, which Microsoft used to indicate the build number, typically this was a daily build at Microsoft.
And then because in some cases they would generate more than one build in a given day, they would use the fourth part to indicate of seconds since midnight. Well, actually it's the number of seconds since midnight divided by two, because the number of seconds in a given day is actually a little bit larger than what you could represent in a two-byte digit. We reference this inside of code by going into the aforementioned AssemblyInfo file. And so specifically towards the end of that file, you can see where they say Major Version, Minor Version, Build Number, Revision here in the comments.
Specifically we're using the Assembly Version attribute. Now you notice that they have both AssemblyVersion and AssemblyFileVersion. This is the one that the CLR really cares about. The AssemblyFileVersion is used more for installation purposes. And here, you'll notice that we explicitly set all four digits. Now, you can set these however you'd like. You don't have to use Major/Minor Build and Revision, however, there are a couple of things that the CLR will key off of. In particular, it's going to track the Major and Minor Version inside of the code, and it will make certain decisions around what assemblies to load, based on these numbers.
Again, how those decisions are made are going to be the focus, not of this course, but of the Assembly Resolution Course. So you may want to check that out, if that is of particular interest to you. To change these values, obviously we can just go ahead and change a value like so here for HelloWorld, but as a matter of fact, let's actually go into People and let's go into its AssemblyInfo, and down here we're actually going to change the version from 1.0 to 1.1.
After we do a Control-Shift-B to build the whole thing, we'll notice that, in fact, the People project will have this new version 1.1, as a matter of fact, let's go over to iledasm and check that. So let's go ahead and File, Open, People, notice we're looking at People, always good to verify that, manifest, and if we look at the assembly for People down here at the bottom, Version 1.1, okay? Now, let's close that and let's go back and look at HelloWorld.
So, verifying that we're looking at HelloWorld, if we pop open the manifest, we can see Version 1.1. So you can see that assemblies are definitely tracking the version numbers of their various dependent assemblies. Now, one of the other things, particularly in a world where we are looking at doing things like continuous integration, continuous deployment, one of the things we would like to do frequently, is we would like to be able for our libraries to, in fact, track build numbers and number of seconds, and so on. And so let's go back into People AssemblyInfo, you'll notice this comment here, AssemblyVersion 1.0.*.
If, in fact, we set an asterisk here, in place of the last two digits, the compiler will actually, at the time of compilation, synthesize the build number and the number of seconds since midnight for us. So again, if I do a complete rebuild of the project, so you can see People.dll modified down here, and if I go back to iledasm, and I ask it to open People, when we look at the manifest here, we will actually see a different version number.
And as you can see, it's Version 1.1:6271:24402. The point is, these numbers are not really all that important, as far as the CLR is concerned, they are used as part of our build process. If you really want to control this number, there are certainly a number of utilities and tools you could use to try to make that a monotonically and incrementing integer and whatnot, but for a lot of build processes, just knowing that there is a non-zero value here and then that value will continue to get bigger and bigger and bigger, is the important part.
As a trivia note, this build number here, this is referencing the number of days since .NET 1.0 was first built back in its old alpha day. So if we count backwards, this will actually be a little bit more than 10 or 15 years ago, when Microsoft first started working on the thing that they would eventually call .NET. So, number of days, number of seconds, these constitute your build number and your number of seconds since midnight, correspondingly. And again, if you don't like that particular convention, you are always free to put whatever values you like here.
The asterisk is simply a convenience that Visual Studio provides to you to help you generate more or less unique assembly version numbers. By the way, as you are working with this, as you're compiling code, if all of a sudden for whatever reason, Visual Studio will refuse to build the file that you're looking at, check to see if you still have it open in iledasm. Because iledasm, when it's looking at a file, it locks it and therefore Visual Studio won't be able to write to the file while you're looking at it in an iledasm.
Simply close iledasm, do the build, and then you can reopen it again and you'll see everything will be hunky dory.
- Reviewing the concept of assemblies
- Reviewing library assemblies in ildasm
- Working with assemblies and modules
- Working with assembly scope types
- Reviewing assembly names and versions
- Referencing assemblies from managed code