MyEmployer.Framework
Although this ties in really neatly with the work I am doing out of the office, it actually came up from the office. We have a fairly meaty core framework dll that we use for all applications. I believe it was originally based on the original version of the Application Blocks (before it became the Enterprise Library) however the security model that we use is completely rewritten and much improved. We then have many other assemblys spread over five or six key applications. Some applications use one dll, some use over twenty dlls. It's a prime candidate for rework, and its one of the reasons I am writing CodeStruct, as the relationships are too complex for most developers to spend time digging into, even Reflektor's assembly reference diagram shows a very complex structure as we have 40 assemblies, and a maximum tree depth of 8 assemblies (not including system namespace or Interops). The diagram doesn't even fit on 1600x1200.
How did this come about?
I believe the fundamental issue with this level of complexity is down to projects and namespaces. It's something I have seen at previous companies before and I still see now. The average developer is a very focused fellow with deadlines looming on him. He is reluctant to introduce new projects as it requires a lot of work, it might be code reviewed and he will have to explain his decisions, he can't be involved in complex thoughts about how this get reused amongst the companies applications and likely applications. So when he has to introduce a new project, he does the smallest amount of work he can. It gets named exactly the same name as its namespace, usually Company.Function.
Versioning
One of the biggest problems comes from assembly versioning. We don't use the Visual Studio out of the box auto-increment. i.e. [assembly: AssemblyVersion("1.0.*")]. Instead we use a custom scheme that we manually increment for each release coming up. ie. [assembly: AssemblyVersion("x.y.z.a")]. We also do not use [assembly: AssemblyFileVersion(...)] or [assembly: AssemblyInformationalVersion(...)].
Since we also StrongName our framework assembly, this means that whenever somebody wants to change it, almost every other assembly must be updated too.
However we might be changing. We have a requirement for a quick update and the decision has been made to release the new dll with exactly the same version number as a previous release. Ideally we will add an InformationalVersion or FileVersion, so that it shows as updated. I'm not sure I agree with this change as it's likely to be a headache as the release goes onward, through test system after test system, finally hitting live.
What do MicroSoft do?
The assemblies in the dotnet framework are quite interesting, they look like they are strong named, but following a patch release e.g. .Net 1.1 SP1, they have references between the updated dlls and the original. i.e. 1.1.4322.2032 -> 1.1.4322.573 -> 1.1.4322.2032
The answer becomes obvious if you dig into them with ildasm you find (from System.Data.dll)
.field static assembly literal string InformationalVersion = "1.1.4322.2032"
.field static assembly literal string Version = "1.0.5000.0"
All the dot net framework assemblies for 1.1 are version 1.0.5000.0. They just have a version string that gets displayed of 1.1.4322.
What do you think?
Please comment below.