Tom Hollander's blog

Enterprise Library 4.0 - Get it while it's hot!

It's almost exactly a year since I handed in the keys to the Enterprise Library bus, but I'm still as excited as ever about the release of a new version. The team has just released Enterprise Library 4.0, which features all of the blocks you know and love updated for Visual Studio 2008, plus the shiny new Unity Application Block for dependency injection. As always, you can grab the new release from http://msdn.microsoft.com/entlib and participate in the thriving community at http://codeplex.com/entlib.

Congrats to the entire team for another great release:

• Product Management: Grigori Melnik
• Program Management: Scott Densmore, William Loeffler, Chris Tavares, and Grigori Melnik
• Architecture: Chris Tavares, Scott Densmore  and Fernando Simonazzi
• Development: Chris Tavares, Fernando Simonazzi, and Nicolas Botto
• Test team: Hanz Zhang, Carlos Farre, Rohit Sharma, Naveen Guda, Pooja Parate, Pravin Pawar, Ronita Acharya, Sai Pasumarthi Venkata Appaji Sirangi and Vijaya Janakiraman
• Documentation: Alex Homer
• Edit team: Nelly Delgado, RoAnn Corbisier and Tina Burden McGrayne

Also thanks to everyone who worked on past releases who helped build such a strong foundation, and of course to everyone in the community who has supported this initiative and provided invaluable feedback.

Here's a summary of the official release notice from Grigori's blog:

What’s New in v4.0?

This release of Enterprise Library includes the following:

• Integration with the Unity Application Block
• Windows Management Instrumentation (WMI) 2.0 support and improved instrumentation
• Performance improvements (particularly, in the Logging Application Block)
• Pluggable Cache Managers
• Visual Studio 2008 support
• Bug fixes

Note: existing public APIs (v3.1) are still supported.

The Application Block Software Factory and the Strong Naming Guidance Package are not included in this release but are available as a separate download. Thus, there is no longer a dependency on Guidance Automation Extensions (GAX).

For the detailed list of all changes, see About This Release of Enterprise Library.

Enterprise Library by Numbers:

Getting Started

If you are new to the Enterprise Library:

• read the Introduction to the Enterprise Library;
• download, compile and run the QuickStart samples—study the code;
• read through the related QuickStart Walkthroughs and “Key Scenarios” sections of the documentation;
• practice the Hands-On Labs;
• join the webcast in June 2008 (the exact date will be announced on the Enterprise Library landing page).

If you already know and love the Enterprise Library:

• check out the change log for this release;
• upgrade to V4.0—no code change is required—simply update the references to the corresponding application block assemblies and to the common assemblies;
• download the updated QuickStarts and run through the Unity-integrated examples to get the flavor of new dependency injection style of using the Enterprise Library;
• join the webcast in June 2008 (I’ll announce the exact date later).

Happy Coding!

Thoughts on being a Solution Architect

About a year ago I put together a post called Thoughts On Product Management, containing some random musings about my role at the time. The big reason I put together this post was because so few people had any idea what this job involved or why it is important.

Now that I've got "Solution Architect" on my business card again, I thought it would be worth putting together a sequel post. However the role of "architect" suffers from an entirely different problem to product management, which is that so many people interpret the role in so many different ways. Partly this is because there are so many different types of architects, such as enterprise architects, application/solution architects and infrastructure architects. But even within just one of these job titles, I've see a huge variation in different people's interpretation on the skills, tasks and responsibilities involved.

I'm not going to pretend to be able to answer the question of what a solution architect should do any better than anyone else can. But I did want to share some of my own experiences on what seems to work well - much of it learned from working with other architects on past projects, and hopefully still relevant and effective for my current team. I'd also like to hear your thoughts, whether you are a solution architect or someone who works with one, about where you think the most important responsibilities lie.

When I look at the work of a solution architect, I think it's interesting to separate the "what" from the "how". The "what" side, while definitely not simple, is probably the less contentious. Figuring out how to meet current and future business and non-functional requirements, making sense of new approaches and trends such as SOA, ESB, Web 2.0, federation, etc, and determining where and when to apply patterns are the bread-and-butter of an architect's job. But what does that really mean on a day to day basis? That's where the "how" comes in, and I'm sure that like me you've seen a huge variety of approaches. The stereotypical extremes are the "ivory tower architect", who has a three-ring binder full of Zachman matrixes and UML diagrams but is completely disconnected from reality, and the "developer in denial", who is really just a developer who wants a more fancy job title.

I'm sure you won't be surprised to hear my view that a real architect needs to lie somewhere in the middle. Certainly architecture is a distinct discipline from development. While moving from development to architecture is a common career path, just because you are a good developer does not mean that you are necessarily destined to become a good architect. And the reverse is also true - most architects (myself included) are not able to keep up with the coding skills of the developers on their teams, especially once they stop full-time development. That said, I personally do not see how someone can be an effective solution architect without some kind of development background and a thorough understanding of the application's ever-evolving code base.

So without further ado, here are some of my current thoughts on what being a solution architect (specifically one in an agile team) is all about.

Minimise the amount of code the developers need to write

Developers are paid to write code, and they are generally excellent at it. However once a developer is assigned a swag of requirements or stories they need to get down to work on those specific requirements, and it's not easy for them to keep up with what everyone else is doing in any level of detail. This can include discovering synergies between different requirements or opportunities for macro-level code reuse and refactoring. A big part of the architect's job is to pick up on these opportunities as they arise and ensure that developers aren't reinventing the wheel in their own worlds. Ideally this should result in patterns, components and frameworks that allow the developers to get their requirements done with less code, by concentrating on those parts that are unique.

Ensure an approach works before you ask the team to follow it

While it's nice to be able to replicate approaches that have proven successful in the past, new technologies and unique projects mean that it's often necessary to break new ground. Dealing with these challenges is a part of the job for everybody in the project team, not just the architect. However when there is a work coming up which will require the attention of multiple developers at the same time, those developers will be a lot more productive if they are given some initial guidance on how to approach the problem. Some architects like to communicate to developers with documentation, which can be fine when the approach is well understood. But when the solution has never been tried before, I believe it's critical for the architect (possibly with help from others) to do enough prototyping to ensure the solution is sound before it's handed over to the dev team for the real work to begin.

Make sure the requirements, and the technical implications are understood before it becomes a distraction

Business priorities and requirements are always in flux. The great thing about agile projects is that this fact is embraced rather than feared. Good developers and testers are able to cope with change well through high test coverage and continuous refactoring - but at the same time it's important that developers don't get too distracted while there is still considerable churn in requirements. Understanding how new requirements get injected into the project is largely the domain of product and program managers, but the architect has an important role to play too. In many situations I've found that the business stakeholders will modify, reprioritise or cut requirements based on advice on the technical implications. This process can take some time, and I believe it's important to shield the development team from most of these discussions so they can concentrate on implementing and testing the requirements that are better understood.

Put together just enough design docs and diagrams, just in time

I've seen a huge spectrum of opinions on how much, and what kind of documentation architects should produce. In my experience, face-to-face discussions over a whiteboard or computer terminal are normally a far better communications tool than any kind of documentation - however this does not mean that documentation has no value. In particular when there is a need to persist ideas or solutions for the team or external stakeholders, documentation is unavoidable. My strategy is to write documents only if I can identify the exact individuals who need it, and to hold off on writing the documents to the last responsible moment (to avoid rework when everything changes). In practice I tend to produce small design documents (typically about 5 pages long) throughout the project that each drill down on one specific topic. This may include a few block or UML diagrams, but I don't like to use any standard templates as each topic will require a different level of detail and will need to be explained differently.

Do enough development work to stay relevant

Whenever someone assigns me a requirement or a bug I often joke that if they want it done anytime soon they really should assign it to somebody else. There is quite a bit of truth to this - on any given day I'm randomised enough to make it difficult to make a lot of progress on development tasks. Still I believe it's very important to have these tasks on my plate (especially when I get the fun ones!). The main reason is that it forces me to stay familiar with the code base and the day-to-day issues facing the team (like how long it can take to check in!).

Help with questions, problems and code reviews at any time

I've left this one for last, but I think it's the most important part of my job (and definitely most time consuming!). On any given day most of the developers in my team will come up with unexpected issues and questions. In most cases they can be resolved with a quick chat or whiteboard session, and in almost all cases everybody involved contributes great ideas that help shape the solution. Since these kinds of issues are by definition unpredictable, helping people out with these can be quite a distraction. However if somebody isn't available then small issues can become major roadblocks very quickly. In addition, participating in these discussions helps me keep my finger on the pulse of what issues the team is facing, and can sometimes uncover a need for the overall architecture to be revised to minimise future issues.

So consider this one more opinion to add to an ever-growing collection of thoughts on this topic. As always, I'm always very interested in hearing yours as well.

Enterprise Library 4.0 Community Technology Preview

From Grigori:

We are pleased to announce the release of the EntLib 4.0 March 2008 CTP and invite your feedback.

This release has been adapted to work with WMI version 2.0 and version 3.5 of the .NET Framework.

Enterprise Library 4.0 has the Allow Partially-Trusted Caller attribute (APTCA) on all assemblies. This means that you can call the methods of Enterprise Library and the application blocks from an application running in a partial trust environment. You can do this with the signed assemblies provided with Enterprise Library. There is no longer any requirement, as there was in version 3.x, to recompile the source code then either use the unsigned binaries or strong-name them yourself.

The Caching Application Block has been refactored to allow developers to replace the CacheManager class with other implementations, including the ones offered by the distributed cache solution providers. This does not affect the API of the application block.

There are also additions in functionality to the Logging Application Block, the Validation Application Block, the Exception Handling Application Block. For details see the change log on the release page.

Note: This community preview does not include the integration with Unity or the integrated Visual Studio 2008 config tool. These features are plannned for the final release.

EntLib4.0 March 2008 CTP download site

We look forward to your feedback!

As always, the team is always looking for your feedback. The CodePlex discussions are generally the best place to provide it.

Cool New Stuff on CodePlex

In the last few weeks there have been a number of interesting new projects added to CodePlex that you may want to check out.

Resource Application Block

Stephen Phillips has just checked in a complete application block to the EntLibContrib project. We haven't got around to packaging together an official "release" in a while, so you'll need to grab the code directly from the Source Code tab for now (but hopefully someone, maybe even me, will put their Release Manager hat on soon!).

So what's the Resource Application Block all about? Here's what the docs have to say:

The Resource Application Block is all about resource management, localization and globalization. The Resource Application Block gives developers a provider model to get to resources from a variety of different sources and source types using the features of the Enterprise Library 3.1. All configuration of those resources naturally uses the Enterprise Library Configuration Console.
The developer is not limited to the providers out-of-the-box but can extend the block by adding providers of their own in the normal Enterprise Library extensible fashion.

p&p Documentation Tools

The patterns & practices documentation team, consisting of Nelly Delgado, RoAnn Corbisier, Tim Osborn and additional contract writers too numerous to mention, have for a long time been investing in tools to streamline the development and publication of technical documentation. If any of you have ever tried to put together CHM or HxS help files, complete with links, indexes, TOCs and integrated API docs, you'll understand why these tools were developed.

While most people are probably unaware of the existence or the need for these tools, those that knew about them have been pestering the doc team for years asking if they could use the tools themselves. The answer was always along the lines of "sorry, we'd love to help, but the tools were designed for internal use". However the pestering must have finally paid off, as these tools have now been cleaned up, documented and published on CodePlex for the entire world to try. Here's what the team has to say about the Doc Tools:

We are pleased to announce the availability of the patterns & practices Documentation Tools. These are the tools that have been used to create the accompanying documentation for many p&p projects, including the Enterprise Library, Smart Client Software Factory, Web Client Software Factory, and Web Service Software Factory. The tools allow authors to create guidance using Word 2007 and produce documentation in HTML, Help 1.0 (CHM), or Help 2.0 (HxS) format.

The Documentation Tools include three binaries that you can install:

• Content Template. This is a Microsoft Word 2007 add-in and template that provides the p&p Content ribbon bar and pre-defined styles to create and format content.
• Master TOC Tool. This tool allows you to specify one or more Word documents to be converted by the conversion tools.
• Conversion Tool. This tool consists of transforms and Powershell scripts that convert your content (written in the Word template and specified in the Master TOC) to HTML, Help 1.0 (CHM), or Help 2.0 (HxS) format.

Hawkeye

Corneliu Tusnea is a consultant from Readify and the development lead on my current project at the Microsoft Solutions Development Centre. Corneliu knows more about the inner workings of the .NET CLR than almost anyone outside Microsoft, and for some time he's been using these powers for good (and maybe just a little bit of evil) by developing a debugging tool called Hawkeye. This tool lets you attach to a running .NET application to view and modify its properties. The tool has been available for a while, but (probably because I keep him too busy at the SDC to continue to maintain the code himself :-) he's just released the source code to CodePlex. Here are a few more words about the tool from the site:

Debugging a managed Windows application is, most of the time, not an easy task. Thus, any tool that can help will make your life easier. Hawkeye is the only .NET tool that allows you to view, edit, analyze and invoke (almost) any object from a .NET application. Whenever you try to debug, test, change or understand an application, Hawkeye can help. With a unique option to Attach to any running .NET process, Hawkeye offers an impressive set of functionalities seen in no other product.

Polymorphism and the Validation Application Block

The Validation Application Block is a useful piece of technology, but unfortunately it doesn't get along too well with that slippery character called Polymorphism. This is because you need to tell the block the exact type in which it should look for validators - it won't automatically figure out what the real type of your instance is.

For example, consider the following type definitions:

public class BaseClass
{
    [StringLengthValidator(1, 5)]
    public virtual string A
    {
        get;
        set;
    }
}


public class DerivedClass : BaseClass
{
    [StringLengthValidator(1, 5)]
    public string B
    {
        get;
        set;
    }
}

Now if I validate an instance of DerivedClass using Validation.Validate<DerivedClass>, everything works as expected. However if I validate my DerivedClass instance using Validation.Validate<BaseClass>, it will completely ignore property B and its validators. And that is rarely a good thing.

Of course if you know that your instance is a DerivedClass, you can simply call Validation.Validate<DerivedClass>. But the whole point of polymorphism is that you normally won't know which specific concrete type you have. Luckily there is a simple solution, which is to use one of the overloads of ValidationFactory.CreateFactory that lets you specify the target type using a non-generic type parameter, as in the following example:

[TestMethod]
public void ValidateActualTypeWithInvalidDerivedClass()
{
    BaseClass b = new DerivedClass() { A = "Valid", B = "Invalid" };
    Validator validator = ValidationFactory.CreateValidator(b.GetType());
    ValidationResults results = validator.Validate(b);
    Assert.IsFalse(results.IsValid);
    Assert.IsTrue(results.ToArray<ValidationResult>().Length == 1);
} 

This works well if you want to want to manually validate a specific instance. However things get even more tricky if you have a hierarchy of types that you want to validate with the help of the Object Validator. Consider the following type:

public class ContainerClass
{
    [ObjectValidator]
    public BaseClass NestedClass
    {
        get;
        set;
    }
}

In this case I can set my NestedClass property to a BaseClass, a DerivedClass, or some other subclass which I haven't thought of yet. Ideally, whenever I ask the VAB to validate my ContainerClass, the rules should kick in for whatever flavour of class I choose to set in my NestedClass property. It would probably be possible to build a supercharged ObjectValidator attribute that does this, but failing that there isn't any way that I know of to apply my previous trick to get the block to look at the concrete type for validation rules.

However I did stumble across the following hack that seems to work well. I used "self validation" to create an additional method on the base class which effectively delegates validation to the derived class:

[HasSelfValidation]
public class BaseClass
{
    [StringLengthValidator(1, 5)]
    public virtual string A
    {
        get;
        set;
    } 


    [SelfValidation]
    public virtual void Validate(ValidationResults results)
    {
        if (this.GetType() != typeof(BaseClass))
        {
            Validator validator = ValidationFactory.CreateValidator(this.GetType());
            results.AddAllResults(validator.Validate(this));
        }
    }
}

The "if" test in the self-validation method is necessary to prevent an endless loop with the self-validation calling itself. With this hack in place, the following test now passes. In fact, it's also possible to validate a DerivedClass using Validation.Validate<BaseClass> as well!

[TestMethod]
public void ValidateContainerTypeWithInvalidDerivedClass()
{
    ContainerClass c = new ContainerClass() { NestedClass = new DerivedClass() { A="Valid", B="Invalid"} };
    ValidationResults results = Validation.Validate<ContainerClass>(c);
    Assert.IsFalse(results.IsValid);
    Assert.IsTrue(results.ToArray<ValidationResult>().Length == 1);
}

I admit this hack is a little ugly and ideally wouldn't be necessary. However it's also very simple and does not require any changes to the Validation Application Block source code, so it seems to be a good solution for now.

Gosh! GAT/GAX is Golden!

Hot off the presses: the February 2008 release of the Guidance Automation Toolkit and Guidance Automation Extensions is now available. In addition to a number of new features, it's great to see that GAT/GAX has finally been allowed to graduate from Community Technology Preview to a "real" release.

Here's the official rundown of what's in the new release, courtesy of Grigori (with just a few fragments left over from my previous release notes :-)

New In This Release

The February 2008 Release of the Guidance Automation Extensions and Guidance Automation Toolkit has the following improvements to the earlier release, the July 2007 Community Technology Preview:

• Support for Visual Studio 2005 and/or Visual Studio 2008. This version of GAX will run on either version of Visual Studio. If you don’t have GAX installed, you can install GAX to support Visual Studio 2005 or Visual Studio 2008 or both. The installer will automatically determine which versions of Visual Studio you have installed.
• Updating GAX.
• If you have a previous version of GAX installed on Visual Studio 2005, it will be updated to the February 2008 release of GAX. You are no longer required to uninstall GAX and the corresponding guidance packages.
• Guidance packages that are registered with the previous version of GAX will automatically be registered with the current version of GAX (GAT, however, will require an update – see the information below).
• Visual Studio side-by-side support. If you have Visual Studio 2005 and Visual Studio 2008 running side-by-side, you can have GAX running against both versions. Guidance packages developed and registered through GAT for a specific version of Visual Studio (2005 or 2008) will only be available in that version. Guidance packages designed for Visual Studio 2005 and installed through an MSI will only be available in Visual Studio 2005. Installation of any guidance package through an MSI that does not explicitly prompt for the version of Visual Studio to install to, will install to Visual Studio 2005 by default.
• Improved Uninstaller. During GAX uninstallation, you can click the Check Installed Packages button for the list of all registered guidance packages. If you proceed with GAX removal, the uninstaller will only attempt to automatically uninstall those guidance packages that were registered manually using GAT. If you have guidance packages that were installed through an MSI(s), you should not proceed with removing GAX. Instead, you should use the Add or Remove Programs tool to uninstall these guidance packages.

In addition, this release of GAX has the following fixes:

• A blank error message was displayed if you attempted to uninstall GAX before uninstalling GAT or other registered packages when running Windows Vista.
• A FileLoadException error was displayed if you used the Guidance Package Manager on Visual Studio 2008 Professional.
• GAX and GAT would not properly validate and recognize custom Visual Studio project types when unfolding templates for custom project types registered only in the experimental hive.

Congrats to the entire team for another great looking release!

Why your customers will love agile (even if they think they hate it)

Project management methodology has never been a particularly sexy topic. While it's always been necessary to employ some kind of process to guide any non-trivial software development project, in my experience most of the team will only expend the bare minimum effort to learn and follow the process (that is, just enough to get the project manager off their back). It definitely isn't a topic that's likely to create heated discussion at the team's Friday night drinks.

Well that was true, until the advent of agile development. For some reason, whether they love it or hate it, everybody loves talking about agile. For example, Microsoft's own internal discussion list on agile development often receives dozens of posts each day, and the company isn't even a particularly big follower of agile approaches. It seems project management is sexy again.

But one of the most fascinating aspects of this is that the interest and adoption of agile approaches tends to be driven mainly by developers. Not project management types, not management and not customers. I can't offer a good explanation of why this is the case, but I do think it's great to see developers taking a front seat in driving the evolution of our discipline. Still I find it strange that the people who probably have the most to gain from the benefits of agile are often the least willing to give it a go - the customer.

In some cases this may have been brought on by a bad experience with a team that used "agile" as a synonym for "having no process at all" or "not thinking ahead". These kinds of experiences are unfortunate, but hopefully will become less common as the growing interest in agile turns into practical experience and development teams start to understand that agile projects require at least as much discipline as waterfall projects, albeit of a very different type. However in my opinion a bigger reason why many customers fear agile projects is that they are so used to being promised a fixed scope on a fixed date with a fixed budget, but agile projects will never give that promise. On an agile project the customer does not know upfront precisely what they are going to get for their money. On a traditional project, they know exactly what they are going to get. Of course, most traditional projects blow out in schedule, scope, budget or all of the above, so the customer probably won't get what they wanted at all - but at the time the deal was signed, all was crystal clear and the ultimate failure of the project was clearly someone else's fault.

Some months ago I posted about the challenges with selling customers on agile processes, particularly in competitive tender situations. This post generated some fantastic discussion in the comments, and it's not my intention to go over that same ground again. Instead I want to talk about how customers who reluctantly or accidentally end up employing an agile development team will learn to love it, provided the team knows what they are doing. This all comes from my own experience, not just as an architect on agile projects, but as a "reluctant customer" myself. As I've probably mentioned before, when I joined patterns & practices as a Product Manager (aka "customer proxy") I knew practically nothing about agile development but found myself working with an agile team. After a few weeks of bewilderment, it dawned on me how empowering this development approach was for me, "the customer". Whenever new information changed my previous assumptions on requirements or priorities, the team was completely happy to allow for this. No change request forms. No complaining. No schedule blow out. These guys, thought I, are on to something here.

Let's explore some customer realities and how agile development can help:

No matter how detailed the original requirements, some things cannot be anticipated until you see the application in action.

I've worked on projects where requirements have ranged from 500 page specs and dozens of UML diagrams, to scribbles on the backs of coasters and random conversations. While the level of detail between these extremes is obviously very different, the one thing they have in common is that neither accurately reflected what was eventually delivered. Even though the whole point of requirements analysis is to get as deep an understanding of the business needs as possible, some problems or needs will only surface with real users interacting with real functionality. In some cases these problems can be overcome with minor tweaks, in others they will require significant parts of the system to be thought about differently. Either way, the ability to identify these problems early and inject new or changed requirements into the backlog is critical to ensuring that the product that gets delivered is what the business really needs.

A lot can change in the business during the life of a software development project.

Many software projects can span two years or more, even before their schedules slip. And of course, a lot can change in two years. Competitors can launch new products. Business strategies can change. Divisions can be reorganised. Mergers and acquisitions can occur. In short, almost all the business drivers that led to the project's existence are subject to change. Projects that are unable to course-correct are either cancelled, or will be essentially useless when they are delivered.

Development cost does impact prioritisation.

Like it or not, software development estimates have a pretty high error rate. Even if requirements stay relatively stable, the complexity and rate of change of software makes estimation very difficult. Many organisations have estimation methodologies that can prove quite good for a complete project, but even then it's likely that some requirements will take twice as long as expected and others half as long. Many feature prioritisation decisions are made with an explicit awareness or implicit assumption of development cost. If the costing changes, the prioritisation may change too - for example, if feature A is cheap then it's really important, but if it turns out to be really expensive then the business may decide that features B, C, D and E are more appropriate. Agile projects allow updated costing information to be made available, and decisions made, in real-time. In a waterfall project the scoping and prioritisation decisions are generally set in stone before accurate costing is possible, and a blow-out in one feature can blow out the entire schedule.

When you've gotta ship, you've gotta ship.

Every project has a budget. While some projects are in a better position to secure additional funding than others, no project stakeholder wants to go back to their superiors and explain that the money has run out and they have nothing to show for it. Imagine needing to report one of the following possible outcomes at the time that funding for a project runs out:

1. The project delivered everything we wanted, on schedule and on budget.
2. The project delivered the most important functionality that we wanted, on schedule and on budget. If we decide the remaining functionality is needed, we can get this done for approximately $x more.
3. The project has run out of time and money and they haven't delivered anything yet. However if we can secure $x in more funding, we should be able to get it finished.

Obviously everybody would want to go to the board with outcome 1, but if the estimates were inaccurate or the scope changes, outcome 2 will certainly look better on your performance review than outcome 3 - especially if the additional $x is not forthcoming.

So what's the bottom line? A customer working with a high quality agile development team:

• Has more chance of getting business value delivered within an allocated budget,
• Has more chance on getting what the business actually needs, not what they originally thought they wanted, and
• Is empowered to make tough decisions throughout the project, and has the current project status information to inform these decisions.

Who could ask for anything more?

Dialog Box of the Week

Luckily for me, it didn't actually take quite that long.

Unity + EntLib = ?

If you've been following Grigori Melnik's blog, you'll know a bit about Unity, the new Dependency Injection container that's coming in Enterprise Library 4.0. Unfortunately I won't be able to make it to the Unity Extensibility Workshop later this month (it's just a little bit out of my way), but I was lucky enough to have Grigori and Scott Densmore (yes, he's back!) give me a quick overview of Unity the other day, and I have to say it looks very nice so far.

However this initial presentation was really only about Unity as a stand-alone beast. That's fine - it's important to know that it can be used independently of the rest of Enterprise Library if you so wish - but the thing that I'm really interested in is how Enterprise Library application blocks will be "refactored to take advantage of Unity" (direct quote from Grigori's blog). There are a few clues in Scott's latest post, which focuses primarily on how this change will clean up some of the under-the-covers plumbing in Enterprise Library. This is a worthwhile goal (I've never been a big fan of the countless factories and assemblers), but I'm yet to fully understand what impact this will have on the average developer who, let's face it, doesn't normally need to look under the hood to see how it all works, provided it does all work.

In general, a key benefit of using dependency injection is that code can take a dependency on only the interface of a component, plus it needn't worry itself on how that object is created. This is particularly useful if you want to allow different implementations to be used at different times (such as mocks for unit testing), or if you need flexibility in how those instances are going to be created. It's a very useful pattern, but since the Enterprise Library application blocks already include several layers of abstraction internally it isn't obvious what advantages the Unity integration will provide.

To give an example, let's look at how a developer may call the Logging Application Block and Data Access Application Block today:

Logger.Write("My message", new string[] {"Category1", "Category2"});

Database database = DatabaseFactory.CreateDatabase("Northwind");
int result = database.ExecuteNonQuery("spDoStuff", 5, "Foo");

Now in both of these cases, the developer doesn't know what concrete instances are created (TraceListeners, Filters and Formatters for the Logging Application Block, Databases for the Data Access Application Block). They also don't need to worry themselves about how those instances are constructed - granted the options are limited (configuration- or sometimes attribute-driven), but at least this is hidden behind the factory or facade.

So what might these blocks look like when accessed via Unity? I haven't seen any code that describes this yet, but I imagine it will need to look something like this:

// First set up the unity container and tell it how to configure the blocks.
// I have no idea how this will work, so let's not speculate :-)

ILogger logger = unityContainer.Get<ILogger>();
logger.Write("My message", new string[] {"Category1", "Category2"});

IDatabase database = unityContainer.Get<IDatabase>("Northwind");
int result = database.ExecuteNonQuery("spDoStuff", 5, "Foo");

Now ignoring any potentially necessary bootstrapping code, this isn't drastically different from what we do today, although it would be a little more verbose for facade-based blocks such as Logging, Exception Handling and Validation. But what benefits does it provide? Well, for one thing, I could provide a completely different implementation of either block without changing my code. This sounds attractive, until you consider that your new implementation must have the exact same semantics of the original block - for example it would need to use the same LogEntry with the same properties, utilise categories and filters for the same purpose, and so on. So really I can't imagine why you would ever want to use a different implementation, since it would essentially need to behave identically to the current block. The pattern makes a bit more sense for the Data Access Application Block, but it's not really any different to what you can already do with the existing API using derived Database classes.

Scott made it very clear on his blog that they are not planning on doing away with the current block APIs anytime soon, so there isn't any need to panic. But still I think it makes sense to ask what benefits EntLib users will get out of this refactoring exercise, given that the team could be spending time on other priorities. I also know (as does Scott, more than anyone), that changing the core architecture of EntLib is very time-consuming, given that there are seven different blocks built on top of it.

Still I am willing to be sold on this effort. I would like to see the internal architecture cleaned up and I would be very happy if building and extending blocks were made a little easier. And if someone can explain to me how the Unity integration will make my life as an architect and developer easier, I'm more than willing to listen. But in my wishlist for EntLib 4.0, I have to say that other things are higher up on my list, so I'd like to hear the team explain exactly what we are getting out of this and why we would want to change the way we've been using the blocks for the past three years.

If you agree or disagree with me, or if you can inject any additional information into the conversation that will help me or the EntLib team think about this differently, please speak up - as you know, this is the kind of dialogue that patterns & practices team, and the developer community as a while, continues to thrive on.

Unity Workshop in Redmond

In case you missed it, the "Dependency Injection Application Block" promised for Enterprise Library 4.0 is now called "Unity". (As an aside, I find it quite interesting how Microsoft's product names have been changing lately - in no time we've moved from names like "Windows Communication Foundation" and "Guidance Automation Extensions" (my fault :-) to names like "Silverlight", "Zune" and "Unity"!).

Whatever it's called, I'm sure a lot of you are excited about the prospect of a fully-fledged dependency integration framework in Enterprise Library and the opportunities presented by the combination of dependency and policy injection.

While I'll probably need to wait until Unity hits the streets to get a deep understanding of what it has to offer, if you're able to get to Redmond on 18-19 February 2008 you can get a big head start by participating in the free Unity Extensibility Workshop. Full details on the workshop, including pre-requisites and registration details are available in Grigori's post.

So, what did you watch last night?

When I was growing up, we had two TV channels in my area: ABC, the government-run channel, and Capital 7, the commercial channel. While I don't really want to go back to that world, I do remember it with a certain amount of nostalgia. While the number options was obviously abysmal, there were some interesting social benefits: on average, 50% of the people you talk to (provided they were watching TV at all), were watching the exact same show as you. This meant there was always something to discuss. Even when the shows were bad, the conversation was there (in fact, this was probably when it was at its best). The conversation normally went something like this: "Wasn't yesterday's episode of Voltron terrible?" "Sure was - worst this year I reckon!".

Compare this with today's world where many people have 200 or more cable channels to choose from. Even after you take into account that 90% of those channels are inherently unwatchable, the number of options is still sufficient that it's highly unlikely that your friends or colleagues were watching the same thing as you. This brings up the horrifying prospect of needing to talk about something else: politics, philosophy, or heaven forbid, whatever it is you're meant to be working on.

Social issues aside, there are some personal downsides to having so many options to choose from. When I first moved to the United States I had 100 odd analogue cable channels with no Electronic Program Guide (EPG). Since I often didn't have a TV guide handy, watching TV consisted of slowly cycling through the channels, looking for the holy grail of something worth watching. Unfortunately Murphy's Law dictated that most channels would have ads as you switched to them, meaning that you either needed to wait 2 minutes for them to finish (only to find out that the show was crap anyway), or switch past it (probably missing the only thing worth watching).

Eventually I switched to digital cable and my Windows Media Centre PC equipped with an EPG. While this avoided the tedious channel switching, I still found the number of choices overwhelming. If I didn't immediately recognise the title in the guide as a show I liked watching, I'd keep looking. Consequently I spent three years watching the same 5 shows plus the occasional movie. There were probably dozens of shows I dismissed that I would have really enjoyed, but like so many things in life, now I'll never know.

Of course, the world of television is undergoing yet another massive transformation. With devices such as Windows Media Center PCs, TiVo and other DVRs, it no longer matters what time shows are on. This makes it even less likely you'll have something to talk about the next day at work (and even if your colleagues share the same taste as you, they'll likely be 2 episodes behind and will beg you not to spoil it for them). And as shows are increasingly made available online, it won't be long until the concept of a particular show being on at a particular time is dead forever.

So is this really progress? In most ways, yes - I love being able to watch Top Gear whenever I please, whether recorded on my Media Center or downloaded from the web. But I will always miss those days when there was always a guaranteed topic of conversation with anyone you may happen to meet, and that was how bloody awful last night's viewing was, and how great it would be if we had more than two channels to choose from.

A Follow-up on PIAB+WCF Integration

Last month I posted an entry describing how to invoke the Policy Injection Application Block at WCF service boundaries by using custom WCF behaviours. Since then I've discovered a couple of new things that I thought you might be interested in.

First, my (OK, actually my wife's :-) February 2008 issue of MSDN Magazine arrived in the mail last week. It contains an article by Hugh Ang and David San Filippo on the exact same topic (source code is here, article is here). Hugh and David's implementation is a little slicker than mine - it hooks into the IInstanceProvider extensibility point rather than the IOperationInvoker that I used - the advantage of their approach is the PIAB wrapping is only executed at the time the implementation object is created, rather than every time the operation is invoked. Still, I win the award for getting a solution published first :-)

The other piece of news is that I tried integrating both solutions into my project, and things did not go at all well. In a simple test scenario both worked fine, however in my application, which involves multiple WCF service communications, the application suddenly became extremely unstable. Tests would pass and fail intermittently, the PIAB infrastructure would complain about incompatible types, and occasionally the entire CLR went down with a Fatal Execution Engine Exception. In short, bad stuff. The results were also identical using my original solution and with the MSDN Magazine version.

I never found out exactly what was going on, but I did get a couple of clues. When we had just a single service boundary (Service A talking to Service B), everything was fine. The instability started when we had Service A talking to Service B talking to Service C. In our development environment we have everything hosted in separate IIS applications on the same box. When I reconfigured the applications to run in their own app pools, things became stable again. So it looks as if something about the PIAB/WCF approach is causing some kind of leakage across different services running in the same process. If anyone else can repro or has any theories on the underlying cause, please let me know.

It is possible that the problem we experienced is caused by some other aspect of our solution, so I wouldn't discount this approach altogether without some more testing - however I would recommend exercising a lot of caution. In the end I decided to take my call handler logic (in this case, an improved implementation of exception shielding) and call it directly from a new WCF behaviour without the use of PIAB. This time everything ran smoothly - but it's just not as pretty.

Enterprise Library 4.0 Plan Published!

Happy New Year to you all! The Enterprise Library team has started the new year with a bang by publishing their v4.0 product backlog onto CodePlex. As announced previously, the big ticket item is a new Dependency Injection Application Block, but there are a bunch of other goodies on the list, including:

• Support for and integration into Visual Studio 2008
• Fixes to various quirks in the Validation and Policy Injection Application Block
• More extensibility in the Caching Application Block
• Performance improvements for the Logging Application Block
• Simpler support for Partial Trust

...and several more. While it's great to see the initial product plan, the great thing about agile projects is that customers (yes, you and me) can impact the plan right up until the release. The best place to provide feedback on the plan is by commenting directly on the Product Backlog page, posting to the Discussions or creating or voting on Issues.

Prioritising Validation Results using VAB ASP.NET Integration

One of the many cool features of the Validation Application Block is the simple integration into ASP.NET web applications. By using the PropertyProxyValidator (PPV), you can associate input controls with specific properties of specific types, and the validation rules defined on those types (using either attributes or configuration) will automatically apply to the data in the controls.

While we've found this feature extremely useful on my current project, one issue we've faced is that the PPV will display messages for every single validator that fails. Of course from a technical perspective this behaviour is 100% correct, but in some situations this isn't very helpful. Consider what might happen if a user completing a registration form leaves the "Confirm Password" field blank. If the form was designed with a comprehensive set of validation rules, the following validation results may be displayed in the PPV control:

• You must enter a value in the Confirm Password field
• The Confirm Password field must contain a minimum of 7 characters
• The Confirm Password field must contain at least one upper-case letter, one lower-case letter and one number
• The Confirm Password field must match the Password field.

Every one of these rules is important and correct, but in this case we probably really just want to alert the user that they completely neglected to fill in the field. The other validation messages should only be displayed to users who at least went to the effort to enter something into the text box.

The bad news is that, out of the box, there is no way to do what I want. However the good news is that it's pretty simple to extend the block to do exactly this by leveraging the Tag property on every validator and building a derived version of the PPV.

Every validator has a Tag property, which is designed to let you attach arbitrary metadata that can be accessed from the ValidationResults if validation fails. We originally implemented this to allow people to specify the severity of validation rules. In this case we are doing something similar, although it's more about priority than severity. In my solution you need to specify a tag of "Primary" to every validator whose messages should be displayed first. If and only if all validators tagged with "Primary" are happy, the other validation results will be displayed. So for the example above, you might define the validators as follows:

• [NotNullValidator(Tag="Primary", MessageTemplate="You must enter a value in the Confirm Password field")]
• [StringLengthValidator(1, RangeBoundaryType.Inclusive, 9999, RangeBoundaryType.Ignore, Tag="Primary", MessageTemplate="You must enter a value in the Confirm Password field")]
• [StringLengthValidator(7, RangeBoundaryType.Inclusive, 9999, RangeBoundaryType.Ignore, MessageTemplate="The Confirm Password field must contain a minimum of 7 characters")]
• [RegExValidator(".....", MessageTemplate="The Confirm Password field must contain at least one upper-case letter, one lower-case letter and one number")]
• [PropertyComparisonValidator("Password", ComparisonOperator.Equals, MessageTemplate="The Confirm Password field must match the Password field.")]

So far we are just using the Tag feature as it was designed as a place to store arbitrary metadata - but the PPV won't pay any attention to what you stick in here. The next step is to build a custom ASP.NET validator derived from the PropertyProxyValidator. I called mine the PrioritizedPropertyProxyValidator (PPPV, or P³V :-). This class will simply override the EvaluateIsValid method to check if any results have the magic Tag value, and filter the results accordingly;

public class PrioritizedPropertyProxyValidator : PropertyProxyValidator
    {
        public const string PrimaryValidatorTag = "Primary";

        /// 

        /// Determines whether the content in the input control is valid.
        /// 
        protected override bool EvaluateIsValid()
        {
            Validator validator = new ValidationIntegrationHelper(this).GetValidator();

            if (validator != null)
            {
                ValidationResults validationResults = validator.Validate(this);

                if (!validationResults.IsValid)
                {
                    // Check if any results are tagged as Primary
                    ValidationResults filteredResults = validationResults.FindAll(TagFilter.Include, PrimaryValidatorTag);
                    if (!filteredResults.IsValid)
                    {
                        // Return only the primary results
                        validationResults = filteredResults;
                    }
                }

                this.ErrorMessage = FormatErrorMessage(validationResults, this.DisplayMode);
                return validationResults.IsValid;
            }
            else
            {
                this.ErrorMessage = "";
                return true;
            }
        }

        internal static string FormatErrorMessage(ValidationResults results, ValidationSummaryDisplayMode displayMode)
        {
             // Code can be copied from the original class.
             // Omitted from here for brevity.
             // Can't be reused since it's not marked as protected :-S
        }
    }

That's all there is to it! The PPPV can be used in the exact same way as the PPV, however it will prioritise the validation results to display primary results first, and the remaining (secondary) results only once all the primary validators have passed. If you wanted it would be easy enough to implement more than 2 priority levels, but so far two is plenty for what we're doing.

Dependency Injection coming in EntLib v4

Just a quick note in case you missed Grigori's announcement on the patterns & practices team's plan to focus on Dependency Injection in the upcoming release of Enterprise Library, now apparently known as v4 (not v3.5 as announced previously). If you have any wish lists please provide them directly to Grigori or on the CodePlex site.

My personal vote is to integrate this deeply with the Policy Injection Application Block, allowing for dependency and policy injection in one fell swoop, for example:

IMyService = PolicyAndDependencyInjection.GetMeAFullyConstructedAndPolicyEnabledInstanceOf<IMyService>();

Time will tell if that's what we'll get. But I'm paying a visit to Grigori and the team in Redmond next week, so hopefully I'll get a better picture of what they are planning very soon!