Freigeben über

Enterprise Library and .NET 2.0: What's the deal?

  • Artikel

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.

Comments

  • Anonymous
    May 31, 2005
    This sounds reasonable. The application blocks fill gaps in the logic, Microsoft watches how the blocks are used and puts the functionality into the next release. Proper software evolution!

    I would imagine a true Enterprise Library V2 will be some time away as it takes time to understand what the new framework provides.

    This just means that developers who use V1 on 2005 will eventually have to put up with newbies saying "why are you doing it this way, when 2005 does it for you?"
  • Anonymous
    June 01, 2005
    I have been holding off saying anything since Tom is in charge of “messaging” (I just type...
  • Anonymous
    June 01, 2005
    Thanks Tom for the update. Is there any chance to have a post identifying which existing Blocks will have the most changes to them? I am curious since .NET 2.0 is light years ahead of 1.1 and the effects that it will have with EntLib.

    Thanks again for the post. Nice to see the feedback from the p&p group.
  • Anonymous
    June 01, 2005
    Great post.

    Doing things right takes time. How often do we forget that?
  • Anonymous
    June 01, 2005
    Good things do take time. I am still learning and experimenting with the CF App Blocks. That made me very happy.
  • Anonymous
    June 02, 2005
    Hi Tom,
    Thanks, this was a much needed explanation of where things stand WRT .NET 2.0.
    -Steve
  • Anonymous
    June 25, 2005
    I couldn't agree more with your assessment. It is so easy to move from 1.1 to 2.0 without even noticing all the remarkable changes in there (generics, wow!). Waiting a while to see (and later emulate) a library built to leverage those improvements is a small price to pay.
  • Anonymous
    June 28, 2005
    Tom,
    any update on when we will see the first drop of the Ent Lib for 2.0 ?
  • Anonymous
    July 07, 2005
    As you are probably aware, Microsoft's patterns & practices (aka PAG for Platform Architecture Guidance)...
  • Anonymous
    July 08, 2005
    Tim posted his thoughs on EntLib June 2005 release today. Thanks Tim.
    I'm one of those people who waited...
  • Anonymous
    July 08, 2005
    Tim posted his thoughs on EntLib June 2005 release today. Thanks Tim.
    I'm one of those people who waited...