.net: Version numbers for DLL and EXE?

Question

I recently updated my product (exe) and increased the build number every time in assemblyinfo.cs.

Works great, my product is currently on version 1.5.xx, so increase 4 digits every time I have a successful build.

Now I have my DLL files, which are also part of my application.

What would suggest how to do this? Should I use them the same as my exe ie, 1.5.xx or do I need to create a different version number?

Here I am a little confused.

When my product increases in functionality, I can upgrade from 1.5 to 2.0, but where does this come out of my DLL?

Any versioning tips would be greatly appreciated.

thanks

Answer 1

You will probably get a few opinions, but I would say that it is simple, and the version of the EXE and the DLL remain in sync. I can change my mind if you are really going to release versions of DLL and EXE yourself, but you do not mention this as a requirement. You will use this approach if you process some of your files, for example, third-party components (released on a different schedule from the main product). But then again, if you do not have this requirement, I would say just keep all versions of the files in sync.

The convention that I saw well is to use the first 3 numbers to represent the product version (major / minor, etc.), and the fourth part of the version number represents the version control version (so you know exactly what source the files are from binary file).

Hope this helps,

John

Answer 2

In my opinion, you should have only one assembly file, which is shared in the application. Therefore, it is easy to maintain. And of course, this means that you have the only version for all your meetings, which is an acceptable norm for me. this .

Answer 3

In my opinion, you need to manage individual versions.

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

The version of the DLL must be independent of the EXE that runs it.

Answer 4

Look at it the other way - why do you need version numbers? For example, one answer to this may be to know what is being deployed at the location of some customers.

So, if you have an application that deploys as the main exe and some dlls, and these DLLs are NOT part of any other application, you can feel safe, even if you completely forget about the dll version.

Otherwise, if the dlls are part of several 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 quite large, increase MAJOR if you have completely different classes inside, ...

As for the increase in MAJOR due to functionality, this, of course, is again a personal taste, I would advise there something like:

• increase MINOR if functionality is added and some important milestone is reached.
• increase MAJOR if you change user interface paradigms that suggest that you have done a major redesign or rewrite.

Also: Version Syntax Explanation?

Answer 5

You touched on a very large topic, which can really become as complex as you allow.

Ultimately, the version control option you choose depends on what you need to achieve and how much time you need to devote to support it. These two are directly related.

The two main goals of version control are concurrent execution and tracking. Side-by-side (SxS) allows you to run multiple versions of the same DLL in one application. Without changing the build version number, this is not possible. Tracking is simply the ability to determine the exact snapshot of the code that runs on the clients machine. Both can be achieved by changing the build version, but the first can only be achieved by changing the build version.

Many will recommend that you share the version numbers in all DLL / EXEs - this is a good way to do this, since it is the most simplified approach, it also provides the least deployment flexibility.

For example, if you use some form of contract abstraction (by defining dependencies between DLLs via interfaces rather than specific types), you can split your application into several "version silos". An example of this is the client and server, where interdependence, if defined in the third assembly, your WCFs are contracted. If they are all versioned separately, you can release a new version of the server (provided that it meets the same contract) without affecting the client. And vice versa.

As you can see, you will increase the granularity of the versions as your requirements grow, but this will be eavesdropped.

The best thing you can do is exactly what you do, sit down and plan your requirements, and then outline the boundaries of the versions (which components can be separated by contracts).

It depends on the size of your testing department, but I also recommend that you take a look at the fact that the file version reflects (at least partially) the build number / date. You only increase the assembly version once for each client version, but you must have a different version of the file for each DLL collection that exits the assembly. This is because when you test and find a problem, having these unique DLL identifiers will remove any doubts as to why the DLL was created.

Answer 6

The simple answer is to increase version numbers when making changes. Do not keep EXE and DLL in sync, because there is no reason for their occurrence. A DLL is designed for portability - any EXE can theoretically use it. If you already have a version number for the DLL, use it as the current baseline, and if you change it, increase the version number as necessary.