December 2005 - Posts

• Guidance Automation Toolkit

  Wow, these days it's not easy keeping up with the latest stuff from Microsoft, especially if you're an architect..! The latest thing to be released from the Pattern & Practices team is the Guidance Automation Toolkit. In short, it's a set of tools that simplifies the process of creating templates and wizards for VS 2005. Haven't looked into it much yet, but at the first glance it sure looks impressive. Posted Dec 16 2005, 04:29 PM by anders with no comments Filed under: .NET, Architecture

• Interface design in distributed solutions

  The guys at thinktecture have released a quite interesting email conversation about Interface design in distributed solutions. A rather interesting read which deals with some of the problems that tend to be ignored when discussing SOA solutions. In particular, how to map service interfaces to the underlying components. Posted Dec 16 2005, 10:50 AM by anders with no comments Filed under: SOA, Architecture

• SOA: Sharing Schema AND Class

  Usually, I am very much a strict SOA advocate. I really do believe in the principles of having loosely coupled, interface-based, self-contained services. But, that doesn't mean that you're not allowed to cut some corners once in awhile! One of the problems with doing SOA based development in .NET is the more or less lousy support for true contract-first development in Visual Studio. The main issue is the fact that the XSD-generated classes you get from XSD.exe and WSDL.exe really suck. It is really easy to expose stuff as web services, but if you want to consume the very same services (or other services for that matter) you're suddenly left with very basic support. It can be very annoying when you've spent all that time building a set of custom DTO classes using generic collections, properties etc and you realize that on the client they show up as empty shells with fixed-size arrays and public fields*. So, what's the solution then? Well, why not share BOTH schema AND class? Basically, what you do is that you make sure that the service CAN be used without any class knowledge (i.e. it is still exposed as a proper web service), but you let the client have the option of using the same DTO classes as the service! In the previous version of .NET Framework, this meant doing a lot of manual changes to the WSDL-generated proxy classes. But with .NET Framework 2.0, Microsoft introduced the concept of "SchemaImporterExtensions". Basically, you can write your own extension to XSD.exe and WSDL.exe to tell them to use your own DTO classes instead of generating them from scratch. I've been working on a generic version of such an extension, but today I ran into this article from Microsoft Belgium that explains how to do just that. I'll probably still do my own version (which I think will use a web service to get the mappings between service classes and clr classes), but the article explains the process very well. I wonder why this one hasn't made the msdn homepage..? * I know, in .NET Framework 2.0 you actually can make it produce properties, but those annoying arrays still remain. Posted Dec 06 2005, 10:21 AM by anders with no comments Filed under: SOA, Architecture

• Opening a .csproj file in the Visual Studio 2005 IDE

  Been pulling my hair to find an way to open up a .csproj file in the Visual Studio 2005 IDE. After lots of right-clicking and dragging-and-dropping I gave up and googled it. The answer was on the MSBuild Team Blog all the time. Turns out it's as easy as this: Right click the project and select Unload Right click the (now grayed out) project and select Edit Works splendidly! Posted Dec 02 2005, 11:23 AM by anders with no comments Filed under: Visual Studio

• Structure for Organizing Team Projects

  As seen in previous posts, I have just started messing around with Team Foundation Server. My next area of concern is actually how to divide and organize all our current and future .NET solutions and services into Team Projects. As I wrote in a forum post on MSDN: We are gradually moving to a more and more SOA-based approach where we have lots of rather fine-grained solutions, each of which contains something like 2-4 projects (DAC/BLL/WebService layers etc). All services use a common framework (for the most part using EnterpriseLibrary but with some custom extension) and there are also some dependencies between services. On top of this, we have a couple of web sites (internal and external) and some smart clients that consumes the above-mentioned services. What would be a good way of organizing this? I guess we want a separate project for the common framework. Should we then have one project per service? Or should we try to group "related" services into larger projects? Or should we try to mimic our organization (i.e. try to map projects in MS Project to projects in TFS) which, for example, would mean creating a new project for every major release. I did (finally) find some pointers on MSDN, but they basically say "you can structure it any way that seems to fit your needs" which isn't really that helpful. Hopefully, Brian Harry will keep his promise and blog about this soon. In the mean time, I'll probably try a couple of different approaches. Posted Dec 02 2005, 09:25 AM by anders with no comments Filed under: TFS