Managing Enterprise Library in your organization

As more people start using Enterprise Library, a lot of people are starting to ask some great questions about the best way to manage this resource within their organizations. Even though we designed EntLib to be used on projects in large organizations, it's probably fair to say that the installer and documentation is really focusing mainly on use on a single user's workstation. This is something that we will look at improving in the next version, but in the meantime I know a lot of people are crying out for some advice on how to deal with issues such as strong naming, versioning and deployment. So I'll have a go at describing some techniques that some customers are using successfully (in case you missed it, you should also check out the Enterprise Library Applied webcast where some real customers are describing their experiences). Of course, each organization is different and you may have a good reason for doing something different - but for most organizations, most of the time, hopefully this will make some sense:

Establish a centralized team that 'owns' and maintains Enterprise Library in your organization

Whether you have grand plans to extend and evolve the code, or whether you intend on using it pretty much as-is, it's a good idea to establish a single centralized team that owns and maintains the codebase for your organization. This will give you organization-level control over the code and avoids the situation where many teams or developers make changes to the code resulting in inconsistent, fragmented versions of the codebase. The centralized version can, and should, still evolve, but it will be much easier to manage the code, add features and troubleshoot bugs if you keep the number of versions down to a minimum.

Strong-name and version the Enterprise Library assemblies

Since Enterprise Library is shipped as source code, it wasn't feasible for us to strong-name the assemblies. However strong-naming (and the versioning that comes with the territory) is a really good idea, as it means you can determine the origin of the compiled code with confidence, and it adds additional runtime safety by ensuring that your applications only load code that you trust. Strong-naming is also a pre-requisite for installation into the GAC - so if you want to do this now, or think there is even a small chance you may want to do it later, then strong-naming is for you! Assuming you follow the previous tip and centrally maintain EntLib, strong-naming is easy. First, create a keypair (use: sn -k myorgskey.snk), and keep this key well guarded inside the central team. Then update the attributes in the AssemblyInfo.cs files for each project to refer to this key, or delete all of the attributes in these files and stick these in GlobalAssemblyInfo.cs (sorry, we should have left the attributes out of the AssemblyInfo.cs files in the first place to make this easier... next time...). Once you recompile, you're strong-named! Now just make sure you have a consistent and predictable versioning policy so that your developers can understand what is going on each time you release a new version. I won't discuss best practices for versioning here; hopefully you have some processes for versioning in your org already. If not, we can discuss this some other time!

Give your developers access to the source code and accept suggestions and improvements

So if you maintain EntLib centrally, there's no need to give your developers access to the source code, right? Probably not. The source code is a great learning tool, and you should also encourage your developers to explore the code and come up with suggestions to improve it. So drop the source out of planes (we do!) - but make sure you have processes for accepting good changes into the official version, and try to prevent individual developers or teams to make random changes in their own versions (again, to avoid fragmentation and maintenance problems). And if you strong-name the official version, it will be easy to tell whether people are using the official version or something else.

Deploy Enterprise Library assemblies as a part of your applications

When it comes to deployment, you can choose to deploy a single shared copy of the EntLib assemblies to the GAC, or you can use private assemblies deployed with your applications. While there are pros and cons to both methods, in general I would generally recommend the latter, as it you can get fine-grained control over the assemblies loaded by each app without dealing with complex things like binding redirects and publisher policy. If you choose to do it this way, it probably doesn't make sense to deploy Enterprise Library as a unit to your servers. Instead, just include whatever assemblies you need (which most likely won't be all of them) in the deployment package. If you are using an MSI for deployment, this will run the EntLib assembly installers (to install the instrumentation) automatically. If not, you should run installutil over your assemblies after deployment.

Update (February 7th, 2006): Paul Linton pointed me to KB article 324519 which states that there are known issues with using strongly-named assemblies outside the GAC in ASP.NET 1.1 apps. So you should actually either strong-name AND GAC-deploy the assemblies, or leave then unsigned, private assemblies in ASP.NET 1.1 applications.

Once again, these tips aren't for everyone - so if you have found other approaches that work well for your environment, feel free to comment and share your experiences with everyone else.

This posting is provided "AS IS" with no warranties, and confers no rights.