Erwyn van der Meer

As Jan blogged earlier this weekend, Enterprise Library version 1.1 has been released. Some of the issues of version 1.0 have been resolved, but unfortunately not all. I still have some gripes.

Strong naming

The main problem I have is that it still does not support strong-naming the EntLib assemblies, without you having to edit some 42 different AssemblyInfo.cs files. Also for such a coherent set of assemblies I prefer to have a single version number located in a single file and not 42 potentially different version numbers. For the previous release I compiled an strong-named set of EntLib assemblies with version number 1.0.1.0 after applying source-code "patch 1475" and distributed these assemblies to my team members.

So the first thing I would do with EntLib 1.1 is:

• Put the sources under source control and label them “version 1.1.0.0 original”.
• Remove the line [assembly : AssemblyVersion("1.1.0.0")] from the AssemblyInfo.cs files and place one such line in the linked solution item GlobalAssemblyInfo.cs.
• Remove the lines [assembly : AssemblyDelaySignfalse], [assembly : AssemblyKeyFile("")] and [assembly : AssemblyKeyName("")] from the AssemblyInfo.cs files, and place this in the GlobalAssembly.cs:
  [assembly : AssemblyDelaySign(false)]
  [assembly : AssemblyKeyFile("")]
  [assembly : AssemblyKeyName("EnterpriseLibrary")]
• Check in the changes and label them “version 1.1.0.0 strong named”.

Note: This last line requires that you have imported a public/private key pair into a key container named EnterpriseLibrary. You can do that on a VS.NET 2003 Command Prompt window with the command:

sn -i EnterpriseLibrary.snk EnterpriseLibrary

This prevents issues with VS.NET projects having trouble locating the key file if you use a shared GlobalAssemblyInfo.cs file that points to this key file using a relative path (which you would want to do, so you can pull the source from SourceSafe into another working folder and still be able to compile EntLib).

File sink for logging

And I would not recommend using the FlatFileSink to log to a text file, even though it is thread safe now, so you could use it from an ASP.NET application. This thing is in my opinion not enterprise worthy because it uses a single log file that can grow without bounds. It's a shame that nothing better has been included with EntLib 1.1.

As an alternative, I would recommend the RollingFileSink which is the work of Avanade employee Hisham Baz. The RollingFileSink is able to automatically start a new log file after a predefined size limit has been reached, and/or an age threshold has been reached. It is also able to purge old log files.

One issue I have with the RollingFileSink is with the way it handles time thresholds. For instance, with an age threshold set to one day, the log file doesn't roll over at midnight, but 24 hours after the moment the previous log file was created. This is true to the name of the setting of the sink, which are about the age of the logfile and not about the absolute moment in time. But this behaviour is often not the behaviour that the administrators of the application would like to see.