In my team we create assemblies to attach to extensible released software created and published elsewhere in my company. These assemblies are often specific for an individual client, though some are reused. I want to introduce a couple of standards into this environment – version numbers and installers.
Currently, many assemblies go to clients without adequate versioning. I want to institute automated version number updates so when a client has a problem we can be sure which source code was used in their software.
Currently, assemblies are installed by the individual copying them manually to the correct path and performing any necessary registration. I want to force people to use an installer package so the path and registration is handled automatically.
I could implement the first step by getting people to use:
[assembly: AssemblyVersion("1.0.*")]
But I’d prefer to update the AssemblyFileVersion rather than the AssemblyVersion. This is because I understand that advancing AssemblyVersion combined with our manual installation can lead to multiple versions of an assembly being registered. AssemblyFileVersion doesn’t update automatically, and I’m wary of a solution that requires developers install 3rd party tools. If we had a proper installation process, the problem would multiple versions would go away.
For the second step, if I use a Visual Studio setup project then adding the assembly causes it to try to add other assemblies from the original published software, which I don’t want. I assume I can create this as a patch somehow, but I’ve not worked that out yet. Of course, an installer will require reliable version numbers or things will go badly.
It seems clear having written this that I need to advance both issues simultaneously, but I’d really rather approach one at a time.
Any thoughts for the best way to get over these two issues?
I don’t have nearly enough information to point you to a solution. What are you using to build your application and installers? Desktop F5 build? Team Foundation Server? Cruise Control?
Things to realize:
1) Visual Studio Deployment Projects suck. Yes, I’ll stick by that comment. In your case, the dependency scanning problem you have is unfixable. Even if you right click | exclude the dependency it could scan a new dependency at build time. We even wrote visual studio automation to open the project, right click | exclude everything and then save it on the build machine to avoid this problem. Trust me, it’s a horrible road to go down. Even Microsoft knows it sucks and that’s why it won’t be in the next release of Visual Studio anyways. Use other tools such as Windows Installer XML or InstallShield Limited Edition or Professional.
2) You must update AssemblyFileVersion. This is such a core/foundational tenant of Change Management and it’s critical in getting Windows Installer upgrades and patches to work. AssemblyVersion can be changed at your discretion and is only applicable to Strong Naming and IoC scenarios such as Prism where you write rules on what constitutes a valid class for injection.
3) 1.0.* isn’t what you want. You want a system that increments your version and passes it into your build automation. What you use will depend on what you are using for build automation. I use Team Foundation Server and a project in CodePlex to do my versioining.
4) You should never be building on a developers machine. You should always be using a clean build machine with automated scripts and not F5.