Dreadful. This is not a problem at all. The assembly version, file version, and — bonus! — product version are defined by appropriate attributes with the target
System.AttributeTargets.Assembly
, and nothing else. For example:
[assembly: AssemblyVersion("20.0.0.0")]
[assembly: AssemblyFileVersion("20.0.0.0")]
[assembly: AssemblyInformationalVersion("1.1.0.0")]
All your
sad history of all your legacy is irrelevant. If you project compiles any file(s) with these three lines, your assembly will be compiled into a module with the assembly manifest having the said version. Normally, in modern versions of Visual Studio, these lines are put in the file"
/Properties/AssemblyInfo.cs
", but it has no special meaning at all. Only the application of these three attributes is important.
Also, "*" means that some components of the version are auto-generated by the build, but I would use it only during development; the final product release build (I hope you are going to create a command-line build script/batch, otherwise it's not a real development cycle :-)) should put some concrete fixed version values.
You got the exact recipe. Good luck.
[EDIT]
Another bonus advice.
Migrate your project to the .NET version supported by Visual Studio you have. Usually, this is not a problem at all.
No need to apologize for using .NET v.2.0 — it was quite a decent version, with generics and anonymous methods. Using it was never anything wrong. But with later versions, you will have such an important features as lambda expression and type inference, both extremely convenient things, as more.
—SA