So I'm back from a four day camping holiday at Cannon Beach in Oregon. Camping is always lots of fun, but at the end it's always nice to get back to a world where you don't have to worry so much about mosquitoes, sand, airbeds and that ever-so-long walk in the dark from the tent to the amenities block. Camping also means a welcome break from e-mail, but now that I'm back home I've been spending some time going through it to get ready for the week ahead. Since this was a long weekend in the United States, my e-mail pile was much smaller than usual - but there were still a few things to deal with, including the increasingly common questions "when can I get a drop of Enterprise Library for .NET 2.0", or occasionally "can I have this now please?". Unfortunately I can't answer the first question, and while I can answer the second, most people don't like the answer :-). However I do realize that I owe everyone a better explanation on what is going on, hence this blog post.
The best way to start is to give a refresher course on the purpose of patterns & practices guidance. Essentially, our role is to help customers fill the "gap" between what the platform makes very easy, and what customers try to do with the platform. This gap is not new, not specific to the Microsoft platform, and most likely will never disappear (although it does change over time). For example, when a new version of a development platform (such as .NET) comes out, it will offer better support for certain scenarios that used to require lots of custom code. However, history has shown that there’s always more to do, and customers will start to push the boundaries by moving into higher value scenarios that nobody could have predicted. So as soon as parts of the gap are obliterated by advances in the platform, new, "higher level" gaps start appearing in different places.
Another important property of p&p guidance is that we don't fill the gap with whatever we feel like - we place a lot of importance on demonstrating the best practices of the platform. For code-based guidance such as Enterprise Library, we know that developers won't just use the code as-is, they will also extend the code, learn design techniques from it and copy parts of it into their own projects. So while there are many times when developers choose to rely on nasty hacks or techniques left over from older platform versions, we try really, really hard not to do this for p&p guidance.
So, after this long and winding prologue, what's up with Enterprise Library for .NET Framework 2.0 and Visual Studio 2005? The short answer is that it's taking us longer than expected to get a useful preview build - but you probably already know that since I have previously set expectations that we would have a preview available around now. So let me explain what is making this hard. Remember I summarized the guidance creating process with figuring out "what is the gap" and "what do we fill it with?". This is much, much more than taking the first release of Enterprise Library, recompiling it in Visual Studio 2005 and fixing the handful of breaking changes. .NET 2.0 and VS2005 both include some significant improvements which change both sides of our "equation".
First, let's look at the nature of the "gap" in .NET 2.0. Certain things which were quite tricky to do in .NET 1.1 (which led to the application blocks and Enterprise Library) are much simpler using just the platform. For example, you can now read and write configuration using the System.Configuration namespaces; ADO.NET lets you manage connections in configuration and provides base classes that are common across different managed providers; and ASP.NET extensively uses the familiar "factories and providers" patterns for security and other useful functionality. So many - but not all - of the key requirements addressed by Enterprise Library have become addressed by the new platform. This means that the gap is getting smaller in one dimension. But is it growing in another dimension? Remember I said that as the platform advances, customers tend to push the limits and create new gaps. This will probably happen for .NET 2.0 - but it is too early to predict what this will look like. As a result, for the first release of Enterprise Library for .NET 2.0 we will assume that the important customer scenarios are the same as what we support in our current release. When we learn what this new gap looks like, we will plan how our guidance can help fill it.
Next, let's look at what we fill the (remaining) gap with. While there are places where the gap looks pretty similar in .NET 1.1 and .NET 2.0, the new platform includes some new building blocks that change the way that good solutions are built. This includes small but significant cross-cutting features like generics and partial classes, as well as more substantial improvements in individual feature areas such as configuration or security. For example, ASP.NET 2.0 contains some new providers for security features such as authentication and roles, while it has less to say about other security features such as authorization. If we moved the entire Security Application Block forward in its current form, it would likely overlap with these new features and provide an inconsistent approach for coding and configuration. Not only would this be poor guidance, it would likely confuse people who tried to mix Enterprise Library's security techniques with the new platform functionality. So it's taking us some time to reconcile our requirements with the platform's improved capabilities.
Now while this is making our lives a bit complicated, this is actually exactly what we want to happen. Whenever we kick off a new project, we include a "deprecation plan", which specifies how and when the capabilities will be absorbed into the platform. Being part of the platform means better integration, tooling and support, and also frees up the p&p team to focus on the latest, greatest challenges.
I can already hear you asking "what does this mean for backward compatibility?". Unfortunately it's too early to say much (since we don't know enough yet), but we understand how painful breaking changes are. Our goal is to protect your business logic as much as we can from breaking changes, as long as we are demonstrating best practices on the use of the platform. Most likely, some parts of the new Enterprise Library will appear almost identical to the original version at the public API level, while others will need to change more substantially (in which case we will publish migration guidance - from previous blocks to the .NET Framework 2.0 or from a previous block to a new block). We plan on sharing more about the shape of each of the updated blocks on the community site, so stay tuned.
Finally, I can hear you saying "OK that makes sense - and I'm glad I'm not you - but what am I supposed to do in the meantime? I'm already using .NET 2.0 beta 2 now!" (should I have considered a career as a psychic? :-). We originally considered doing a minimalist port of Enterprise Library (recompiling and fixing the breaking changes), but decided it would be better to wait until we have something that is more representative of our planned direction. We know that other people have undertaken a similar porting effort (one example, that we haven't reviewed, is here) - but we were concerned about a p&p branded version of the same as this doesn't represent true "guidance" for .NET 2.0. However, since our version is taking longer than expected to get ready, we are reconsidering our position on this. Over the next couple of weeks we expect to learn enough to make some firmer commitments.
Sorry for the long post - but I hope this helps explain our current situation. If not, you can always go camping.
This posting is provided "AS IS" with no warranties, and confers no rights.