7

I have been recently versioning my product (exe) and increasing the build number each time in assemblyinfo.cs.

Works great, my product is currently on version 1.5.x.x so in increase the 4 digit each time I have a successful build.

Now I have my DLLs which are also part of my application.

How could I version these? Should I version these the same as my exe i.e, 1.5.x.x or should i create another different version number?

This is where I am currently a little confused.

When my product increases in functionality I can raise 1.5 to 2.0 but where does this leave my DLLs?

halfer
  • 19,824
  • 17
  • 99
  • 186
Martin
  • 23,844
  • 55
  • 201
  • 327

6 Answers6

2

You'll probably get multiple opinions, but I would say to keep it simple and have the EXEs and the DLLs version stay in sync. I might change my opinion if you really intend to release versions of the DLLs and EXEs independently, but you don't make any mention of that as a requirement. You would take this approach if you are treating some of your files like 3rd-party components (which are released on a different schedule from the main product). But again, if you don't have this requirement, I would say just keep all the file versions in sync.

The convention I have seen work well is to use the first 3 numbers to represent the product version (major/minor etc..) and the 4th part of the version number represents the source control version (so you know exactly which source files the binary came from).

Hope that helps,

John

JohnD
  • 14,327
  • 4
  • 40
  • 53
1

In my opinion you should have only one assemblyinfo file that is shared across the application. That way it is easy to maintain it. And of course it implies you have a single version for all your assemblies which is the acceptable norm to me. refer this.

Illuminati
  • 4,539
  • 2
  • 35
  • 55
  • 3
    It depends on whether the DLL's are an integral part of the application, or a project in their own right. I'm currently working on an application that has a library DLL that can be used in other projects. The library DLL has its own assembly info, and we don't guarantee that its version number will match the version number of every other project in which it is used. – Robert Harvey Jun 26 '11 at 17:22
  • 1
    @Robert Harvey, yes - of course. If the dll is not a integral part of the app, then you cannot make it use the shared assemblyinfo. But in this particular question it seems the dll is a part of the app. – Illuminati Jun 26 '11 at 17:27
1

In my opinion you have to manage their versions separate.

Because 2 applications(EXE) can use the same DLL. What version the DLL will be ?

The DLL's version should be independent of the EXE that runs it.

Maxim
  • 7,268
  • 1
  • 32
  • 44
0

Look it from the other side - why do you NEED version numbers? For example one answer to that can be to know what is deployed at some clients location.

So, if you have application that is deployed as main exe and some dlls, and this dlls AREN'T part of any other app, you can feel safe even if you completely forget about dll versioning.

Otherwise, if the dlls will be part of multiple projects, increase their version to ANY scheme that seems logical to you, for example, increase MINOR 1.X.0.0 when you add some functionality or change something rather large, increase MAJOR if you have completely different classes inside, ...

As for increasing MAJOR because of the functionality, that is of course again personal taste, I would advise there something like:

  • increase MINOR if functionality is added, and some major milestone is reached
  • increase MAJOR if you change user interface paradigms, that suggest that you did some major redesigning or rewriting.

Also: Version Syntax Explanation?

Community
  • 1
  • 1
Daniel Mošmondor
  • 19,718
  • 12
  • 58
  • 99
0

You have touched on a very large topic, which really can get as complicated as you will allow it.

Ultimately, the versioning approach you choose will be dependent on what you need to achieve, and how much time you have to allocate to maintaining it. The two are directly related.

The two primary goals of versioning, is side-by-side execution, and tracking. Side-by-side (SxS) is allowing multiple versions of the same DLL to execute within the same application. Without the changing of an assembly-version-number, this is not possible. Tracking is simply being able to determine the exact code snapshot that is running on a customers machine. Both can be achieved by changing the assembly-version, but the first can be achieved only by changing the assembly-version.

Many will reccommend you share the version numbers across all DLLs/EXEs - this is a good way to do it, as it is the most simplistic approach, it also achieves the least deployment flexibility.

For example, if you are using any form of contract abstraction (defining dependencies between DLLs via interfaces rather than concrete types), you may split your application into multiple 'versioning silos'. An example of this would be client, and server, where the interdepency if defined in a 3rd assembly, your WCF contracts. If they are all versioned separately, then you can release a new version of server (so long as it conforms to the same contract), without affecting the client. And vice-versa.

As you can see, you will increase your versioning granularity as your demands grow, but it will incur overheard.

The best thing you can do is exactly what you are doing, sit down and plan your requirements, then map out your versioning boundaries (which components can be separated by contracts).

This next thing depends on the size of your testing department, but I would also recommend that you look at having the file-version reflect (at least in part) the build number/date. You will only increment the assembly-version once per customer release, but you should have a different file version for each collection of DLLs that comes out of the build. This is because when you're testing, and you locate an issue, having these DLLs uniquely identifiable will remove any doubt as to exactly which build the DLL originated.

Adam
  • 4,159
  • 4
  • 32
  • 53
0

Simple answer is to increase the version numbers as you make changes. Don't keep the EXE and DLL in sync because there is no reason for them to be. The DLL is intended to be portable - any EXE could theoretically use it. If you already have a version number for the DLL, then use that as your current baseline and as you modify it, increase the version number as needed.