For a few years now, I've incorporated the EHB into my projects. I have yet to come across any blogs that suggest a technique for choosing the actual policies that one might apply to EHB.

All of the examples I've seen have one of three unhelpful variations:

"General Policy" or "My Custom Exception Policy" "Policy1", "Policy2", etc. "Wrapped Exception Handler Policy" or "Replace Policy" The first variation is not helpful because it is just a giant bucket. Everything fits inside. Policies are only useful if there are more than one, and there is some way to distinguish what should go into one versus another.

The second variation is not helpful because it just makes smaller buckets without value.

The third uses a name which presupposes the way in which the policy will always handle the exception. If I'm the developer, and I know I need to use the "Replace Policy", why don't I just skip the handler and replace the exception on my own? Then all I need to do is possibly log the exception,...

This is one of those little gems I wished I known about a long time ago.

http://blogs.msdn.com/b/smartclientdata/archive/2005/08/26/456886.aspx

The DataDirectory macro allows you to specify what amounts to an application relative path to your .mdb files (for SQL Express, on ASP.NET and smart client deployments).

I'm working on writing a document called a Technical System Design (part of our co-opted lifecycle management) that is going to detail our plans to refactor some applications to fit into our new platform. This document will then advise a small team of developer leads who will then work with their own teams to build up our new system.

To be as thorough as I can (because I can't be everywhere for everybody), I'm relying on Steve McConnell's Software Project Survival Guide.

BTW: Agile methodology is not an option, and I'm not convinced it would be correct to apply it to this project.

The SPSG is perfect for me. This will be my first real lead position, and I'm not just the lead developer – I'm the lead over other leads. This is not counting the role I've had advising and assisting the rest of the team on architecture in which my subsystems will be just a part.

...