Hello. How are you? Enterprise Library for VS.NET 2005 will have API and configuration changes compared to the latest versions (January/June). So will other blocks and a lot of the rest of the guidance....and you should expect this.

er...Is that a roar I hear approaching?

Why can't patterns & practices guarantee back compatibility in guidance, especially APIs of our assets? We want to! but from intent to guarantee is a long shot. That said, we do not change APIs and recommended designs without a reason. And we do try hard to make the changes affect the business logic less than the infrastructure and customizations & extensions. The components with the logic of your apps are your investment, your hard-earned jewels, and we want to preseve it more than anything.

I was asking around about this a lot during the last months - Feedback I've gotten during the field summit at TechReady and from customers coming to the building 20 lab devlabs to do early adoption of VS.NET 2005 is:

1) We need to be better at explaining WHY we broke compatibility
2) We need to give you early heads-up warnings on as soon as we think we'll change something - even if we don't know precisely into what yet
3) p&p should help you deal with the unavoidable changes in two main scenarios:
     a) Forward-compatibility issues when putting old binaries on new platforms,
     b) Migration guidance to move and recompile the code away from old assets to newer assets and the platform features

So... 1) Why do we break compatibility? Of course the precise answer goes by asset, but in general:

- We want to set you up better for the future The patterns & practices deliverables provide guidance 'aligned' (in the general direction) of the MS platform. When you are on your own, you have many options in the way you can design your code today. At the same time, there are many teams inside MS defining what the next wave of frameworks and apis will be like. Part of our mission is to 'align' your designs in the general sense of the platform, for two reasons. First, you don't want your application design to be a dead-end architecture wise when having the option to move to a new MS product. Customers consistently tell me this would worse than an API change. Makes sense to me. Second, the feedback and input you provide on the p&p assets gets channeled to and reviewed by the MS product groups. By making our deliverables increasingly closer to the platform we make your input relevant to affect the long term product so it gets closer to your emergent needs.

- We need to help you make the most of the platform targeted by the guidance . Would it make sense if patterns & practices assets, say, lost 10% performance so they could maintain API equality with a version built for a different platform? That doesn't smell like a good practice. It would be a short-time gain.

Would you move to the product? Of course, you would want to adopt to the MS product that provides similar functionality to a deprecated p&p asset for a multitude of reasons (backwards compatibility, better polish and tool integration, loads of documentation, long-term support with QFE and SLAs etc...it's the PRODUCT! not guidance on how to use a previous product...). Not to mention that you would not find a p&p asset competing with a MS product on the same set of requirements, because we just wouldn't do it. Updater application block and ClickOnce is a great example. If you are using VS.NET 2005 you use ClickOnce, not the UAB. Of course, you may have really specific requirements on the way a client does updates that you may decide to do something different than use ClickOnce- including reuse of chunks of the VS.NET 2003-based UAB, but I would seriously think twice about why your requirements are so special. You should also not expect an Updater bock for that matter. Of course, if we see 80% of folks tweaking / extending ClickOnce in similar ways, we'll continue the dialogue with the team who built it to determine which guidance to give around those needs. But let's get on with the topic du jour, breaking compat:

2) We need to give you early heads-up warnings on AS SOON as we THINK we'll change it

We can't eliminate the fact that thins will change, but if we give early warning of where, and more or less how, it will change lets you make your own tradeoffs and plan your investments. You need to understand the tradeoff here - if you want to know what will change before we actually know what it changes into, we're talking probabilities. Feedback I get is that you'd rather know our forecasts and that we revise them frequently than we keep them in the dark until we have the final precise answer. How do you get early warnings? if you don't see clear roadmaps push myself, our product managers (Tom Hollander, Eugenio Pace and Don Smith) and anyone from our team you can get a hold of (e.g. EntLib über dev Scott Densmore).


3) p&p should help you deal with change: in two main cases: forward compat and migration to newer assets and platform
     a) Forward-compatibility issues when putting old binaries on new platforms, 

               This happens when you put an application, with your own unchanged  binaries and binaries based on our code, to run on a new platform. You should know the CLR team application comaptibility test team runs all p&p application blocks as Tier-1 (high impact) code, so a .NET breaking change that affects these is a 'big deal'. Of course there is no way to predict where breaking changes will happen with 100% certainty, but the .NET team has put together a set of guidelines of things that are considered breaking change as they vary between versions, versus what is not, and we'll be part of that loop moving forward. While 0% is impossible, we can push the chances of issues happening to be quite low.

     b) More migration guidance to move and recompile the code away from old assets to newer assets and the platform

            We haven't done much of this yet but feel free to push us to do more. In my opinion this is a very dynamic body of knowledge, and something we should probably iterate on fast as the pitfalls and techniques are discovered. I would like to have this in a wiki somewhere.

Do these 3 points resonate with you?

Here is the tradeoff we need to navigate - and your input will help inform it. We (customers, partners, product groups, patterns & practices teams) all want the areas touched by common blocks and patterns that stream out of p&p to be part of MS product capability ASAP. But to be able to prove your need (i.e. prove the topics we touch are important to you), to release these things in a faster cycle (e.g. not the year after next), to align you better with future platforms (that undergo periodic redefinements themselves), to be best practices (on what you use today), and to inform the shiny new products with your feedback (so they are smack-on with your needs when they ship), we need to change our deliverables every once in a while. Considering this, let us and the community know how we can help you deal with this change. I've set up a wiki page in Channel 9 so candid thoughts can pile up.

Since the very beginning of the existence of our group, the p&p user community has helped us bring more value each year by giving relentless feedback and keeping us honest. As we deal with this platform change, please be as relentless and as much a partner in figuring out the solution as you have always been. Engage in a constructive dialogue, and we will be able to help you out in better ways.

The result will be better MS products, more focused on your needs, and smoother transitions for you between assets, as we continue to evolve this faster release vehicle to help you make the most out of Microsoft products.