Versioning and Pains - 2

Earlier I wrote about the issues with versioning assemblies when you decide to Strong Name your assemblies. While those pains are for real, I came across some additional patterns which can ease that pain considerably. Example1, Example2, Example3

Essentially, You want to do the following as much as your management team allows you to do that (yeah, its true that sometimes they decide the version numbers :D):

1. Change the AssemblyVersion value during internal builds every time so that your internal test team does not use an older version even by mistake. This works fine if you are working on an application which needs to go through future iterations as well. Once one of the versions is signed off by test team, that particular version becomes the de-facto support version and from thereon, you depend on AssemblyFileVersion for updates/patches. This will ensure that a new assembly does not break hell.

2. If any of your changes are going to necessitate significant changes, push it to next iteration :). Since the changes are significant, it is better to have a new version associated with those changes than to have one version reflect significant differences across its file versions. It may not be possible to avoid every time though but then I guess you are not in luck.

3. Use AssemblyInformationalVersion to tag the metadata information that you want to use for conversations. e.g. "1.0.-Iteration1".

For example, I can have following in my assembly.

[assembly: AssemblyVersion("1.3.6.1")]
[assembly: AssemblyFileVersion("1.3.2015.12121")]
[assembly: AssemblyInformationalVersion("1.3 iteration3")]

Notice that I have used a custom naming pattern in AssemblyFileVersion. It uses Year, Month, Day, Build count. You can use your own e.g. attaching changeset number.

Lastly, the sad part is that "*" is NOT supported in AssemblyFileVersion.

Tracing should be inbuilt in .NET framework

Microsoft's .NET platform has an amazingly performant and extremely useful class called Trace. I use this every time, I need to find some piece of information in the application for debugging/diagnosis purpose. Good thing is that you can leave the statements and have Trace turned off through configuration without worrying too much about its impact on the performance of the application.

Unfortunate part is that .NET framework still leaves you with a lot of work to do for basic TraceIn/TraceOut type of functionality. Either you end up wrapping your implementations through some known patterns like Decorator pattern or you end up making your classes have a complex class hierarchy where implementations are controlled through Base class. There are third party tools like PostSharp available in the market which let you implement this elegantly through AspectAttribute which essentially rewrites your IL code by adding the plumbing code that you would have added manually otherwise. While it is good, it seems a little intrusive to me because it makes your test cases dependent on the "additional rewritten" code and forces you to wade through that to test the actual code.

This brings me to a question - shouldn't .NET framework provide TraceIn/TraceOut functionality by default? I would suggest that it should be in-built and it should let users configure it through configuration file - much like IIS logs. Yes, there would be related security concerns but I am sure there must be clever ways to take care of that too.

Just a thought.