How do I make automatic version numbers work in Visual Studio

I've been asked to add automatic numbering to assemblies in our code library. I've been changing versions from the default 1.0.0.0 to 1.0.* like this:

[assembly: AssemblyVersion("1.0.*")]

It generates a number as I'd like.

However, the code library has many hundreds of DLLs, with many referencing each other. Now when I compile some projects they complain that the version of a DLL needed by a referenced component is not correct and they won't build :(

How can I make this work? We need it so that when a DLL at the bottom of our code library hierarchy is compiled, all other DLLs that reference it work correctly without needing recompiling.

The error I get is like this:

Error   1   CA0058 : The referenced assembly 'Library1, Version=1.0.4146.179开发者_Go百科93
, Culture=neutral, PublicKeyToken=d9c65edd2096ad48' could not be found. This assembly
is required for analysis and was referenced by:
D:\Work\Source Code\Library\Library2\bin\Release\Library2.dll.

The version 1.0.4146.17993 is not correct - the DLL has a higher value. The DLLs are set to Copy Local because the software we deliver requires it (don't ask why). The DLL that's copied locally is the one with the higher version number, which is the one we want it to be.

So far I've tried changing the references to set the "Specific Version" flag to false but this didn't help.

The version numbers that VS generates when you use the 1.0.* syntax are not necessarily going to increment in sequence. The documentation has this to say (emphasis added):

You can specify all the values or you can accept the default build number, revision number, or both by using an asterisk (). For example, [assembly:AssemblyVersion("2.3.25.1")] indicates 2 as the major version, 3 as the minor version, 25 as the build number, and 1 as the revision number. A version number such as [assembly:AssemblyVersion("1.2.")] specifies 1 as the major version, 2 as the minor version, and accepts the default build and revision numbers. A version number such as [assembly:AssemblyVersion("1.2.15.*")] specifies 1 as the major version, 2 as the minor version, 15 as the build number, and accepts the default revision number. The default build number increments daily. The default revision number is random.

If it's vital that you get versioning exactly right, I highly recommend that you use a third-party solution. The Build Version Increment add-in is excellent.

What you want to do is manage the assembly version yourself. Only increment this when you make a breaking change to the assembly's public interface. Changing this attribute makes your assembly incompatible with other assemblies that reference it, even if you didn't change a thing in your code. Instead, the only thing you want to automatically increment is the assembly file version. Unlike the assembly version, this attribute is not checked by the CLR to determine compatibility.

The Build Version Increment add-in gives you the kind of fine-grained control over what is incremented that you need to get this right. It's what probably should be included in VS to begin with.

This is actually a pretty indepth question, and I hope someone answers this in detail for you, but my 2 cents after you get the assembly infos under control is you should look at using Nuget to manage your dependencies. This way when team A releases v2 of assembly X, all they do is put it on your Nuget repo (network share probably) and then you can basically right click < update inside your projects that consume the DLLs.

I would also recommend looking at http://semver.org/ and use Semantic Versioning, if you don't want to follow a system like this one (or institute a similar standard for your shop), it's probably not worth even trying to version your DLLs you're just going to give yourself massive headaches. However using Semantic Versioning will make your version numbers actually MEAN something. And not just be whatever felt like being tagged onto the current version.

Note that the Revision number is not random. It is the time of day of the build. The Build is the day number.

See VisualStudio: translating a build version to a calendar date

delete your reference (in the project that uses it) and re-do it by pointing to the project reference type.

PS: If when you are adding the reference, you choose browse and point to a place the dll will always be, the reference will not be broken!

   > However, the code library has many hundreds of DLLs,

If it is ok for you that all source projects and their generated dll-s have the same version-number you can put the versionnumber into one file that is shared between all dlls as described in shared AssemblyInfo.cs. So you (or the version-number-generator you are using) have to update only one file if there is a new relase/Version.

This does not answer your original question but may be a simple workaroud for the dependency problem.