Fear and Loathing

If you've downloaded the recent release of the MOSS and WSS SDKs, you may be scratching your head wondering where they installed to? After all, they're just some compiled help files and samples right?

Seems that in their infinite wisdom, some young and bright engineer at Microsoft broke Phil Haacks first rule of hardware design (which bodes the same for software design). The computer belongs to me, not you!

It seems the SDK installers will hunt down and find the last writable drive in your system and install there. No questions asked. So if you have a removable drive or something (even a USB key) plugged in, it'll be there. The install paths for each SDK are as follows:

• WSS: \Windows SharePoint Services Developer Resources
• MOSS: \2007 Office System Developer Resources

Check on your highest drive letter in these paths for the files to see if they ended up there. When I first installed mine, I had a USB drive plugged into F: so it ended up there, after pulling all my external drives, it ended up on C:. I don't have a network drive available right now, but I would assume it might install there if you have write privledges.

How's that for posts with the most acronyms? It might be old news to you by now, but MS has finally released the RTM versions of the SDK documentation for both MOSS and WSS. Randall's blog has all the nitty gritty details here. He's also got a great resource called the top 10 resources for SharePoint developers (which is actually 14, who said softies could count?) so check that out here.

As for the SDKs they're final now but wait, there's more... these are the first ones outside of the original core set to be Community Content enabled. Yup, the SDKs allow you (with a passport account and the sacrifice of a willing virgin) to contribute content to any entry, any class, any method, and well... anything in the SDK. So watch for this MVP to bide his time updating the documentation as I can find time, as will others I'm sure. Very cool indeed.

You can download the SDKs directly here:

• MOSS SDK
• WSS SDK

Or maybe 4.0? Paul Gielens got my brain jump started this morning with a post about DDD support in the C# language. Domain Driven Design can be hard to grasp and even harder to implement. Conceptually it's easy and makes sense (at least to me). We all read the books and get the theory, but when the rubber hits the road the biggest question anyone has is "how do I write code that reflects this?". Everyone has ideas and if you take a quick search of the DDD mailing list, you'll see dozens of code snippets all talking about the same thing but implementing it differently. Sure, software development and pattern is like that. Take any one pattern and give it to 3 people and you'll get 5 different interpretations. However as we continue to dance around implementation, we get confused by the terms and sometimes miss the ball.

Here's a DDD type implementation using C# constructs so the intent isn't all that clear here:

Now given the spark that Paul mentioned, here's the same code written in DDD style:

If you've read DDD and internalized Eric Evans' theory around things like aggregates, boundaries, entity and value objects you'll get this. You'll see the domain visually (or at least I do) and understand it. No longer would you have questions like "is x an aggregate of y and where should service z live?". The code tells all. Brilliant.

I love C# but it does have its limitations in that it's just simply regurgitating the language it was based on and has typical constructs like class, namespace, etc. I'm sure (but haven't thought how you could do it) that say a language like maybe Ruby could support this but that's an answer for those smart types like John Lam to answer (although with John at the mothership now and working on the CLR team, anything is possible).

I think it's an excellent idea, my only wish is that something like this could come true someday!

Actually this post has nothing to do with llamas but Flickr never fails me:

I've been personally putting off trying to get my head around Lambda expressions in C# 3.0 for awhile as I'm trying to get everything wrapped up with what came with 2.0 however a little gem has come out of the quagmire we call the internet. My good friend Howard Dierking, not a llama but a certification guy and all around cool developer over at the evil empire, has put together an awesome explaination of Lambda expressions and C# 3.0 by walking us through what we do in 2.0 and now C# 3.0.

His explanation and example makes perfect sense, cuts down the clutter of delegate code, is easy to understand, and if you don't get it now you'll really be in trouble when the .NET 3.5 framework hits. Check out Howards blog entry here and judge for yourself.

It's been a week since I blogged and mostly it's been staying busy with work, trying to get on top of all the projects I have and most importantly remember the passwords for all my VMs that I seem to have now forgotten. However today was a bit of an experience I never had before. I got into a car accident. 24 years of driving and I've never actually had an accident. Call me a wuss, but I drive the speed limit and when the road conditions are bad, I slow down and try to keep my cool. Or so I thought.

As I was heading into work this morning I hit a patch of black ice and slush and away I went. My Suzuki XJ7 wiggled along the highway and slammed head first into the concrete barrier that separates the northbound and southbound traffic. It was a hard enough hit to deploy the air bag and shook me up for a second or two. Then I realized I was perpendicular to oncoming traffic and all I could see was headlights. No, it wasn't a "My life flashed before my eyes" moment. It was just a "This sucks" moment as I saw the oncoming traffic. Lucky for me it was 5:30am so traffic was light and the roads were bad (with a light dusting of snow) so everyone was travelling pretty slow (I was only doing 70-80km/h when I hit the barrier as opposed to the 110km/h speed limit). I got the vehicle off the road and discovered there were two other vehicles involved as they swerved to avoid me and ended up hitting each other.

No injuries, although my thumb hurts like the dickens right now (I think I clenched the steering wheel when I hit the barrier) and my chest is sore when it hit the airbag/steering wheel. The other guys had no injuries and damage was pretty minor to their vehicles (back bumper torn off and dent on the side panel of one truck). My damage was a little more severe as the front end was all crushed in (hood buckled, bumper, lights, grill, etc.) and the back bumper was ripped off when one of the trucks swerved to hit me on the side and caught my bumper with his. All in all, I have a pretty good suspicion that my truck is a write-off but they might be able to fix it.

So a sucky way to start the morning and the rest of the day was being mad at myself for what happened and sorting out all the insurance crap and whatnot (including trying to track down a rental car which is increasingly difficult in this city these days). On the positive side, besides being alive and kicking it opened up the idea of buying a new vehicle so we're now looking at something like a Jeep Compass which looks pretty sexy.

Like I said, this wasn't a life altering event for me. It was an accident (and my first). Yes, with a slight twist of events in the timeline of what went down I could have been writing this from the great blog space in the sky or a hospital bed but I'm not so you move on. However it does remind me to remember to live life to it's fullest each and every day. Slow down, enjoy what you have and what's going on around you, and relax. There are probably bigger things in the universe to worry about so don't get your panties in a knot over something silly like property damage.

I'm a factory kinda guy. Ever since I read Keith Short's book I was enamoured with the concept of how factories work. Microsoft took the ball and got things going with the various software factories they're releasing and now they've updated their Web Service Software Factory.

The Service Factory is a cohesive collection of various forms of guidance that have been build with the primary goal of helping you build high quality connected solutions in a more consistent way with less effort. The Web Service Software Factory comes in the form of a guidance package, that allows guidance to be automated from inside Visual Studio 2005 through the use of a wizard-based dialog than can be modified (by an architect perhaps) to fit the needs of a specific solution.

You can grab the latest release here. As with other factories, you'll need the Guidance Automation Extensions installed to run the factory (and it only runs on the professional SKUs of Visual Studio, not Express).

I was working through a problem tonight regarding dependency injection and CAB. CAB provides a facility to inject services and whatnot into other class using ObjectBuilder, Microsoft's DI framework. ObjectBuilder isn't the same as a DI/IOC container like Windsor Container or Spring.NET (or Jeremy Millers excellent StructureMap) but more like a framework for building containers. However in CAB it serves the purpose we need.

Let's say I have a service that performs lookups and returns me lists of items from some backend system. I would like to use this LookupService in various modules but I don't want the modules responsible for creating the service (especially since I only want one of them and don't want to deal with singletons) and I want an easy way to ensure the service is loaded and ready to go when I need it. Here's where CAB will help you with this.

First let's look at our service implementation:

This is a straight forward service that returns a generic List<> of KeyValuePairs<>. I might use this in my UI in a combo box or whatever, but it's just a lookup of items. The implementation here is hard coded, but you could just as easily have this call out to a database, do an asynchronous web service call, whatever you need.

To share the service, I'll use the Infrastructure.Module project in my SCSF generated solution. This module gets loaded first and using SCSF I have it set to be a dependency so whenever the system loads any module I'll load this one first, ensuring my service is there. Here's my ProfileCatalog.xml that shows the dependency.

The module dependency is part of SCSF so it won't exist if you're just using CAB. In my profile catalog, the moment the Project.dll module loads, it will first load it's dependency module(s) from the Services section of the XML file. You can have as many services as you want here and they'll load in reverse order that they're listed in the file.

To instantiate the service and make it available, I have to load it up and add it to the RootWorkItem and it's list of services. This is done in the ModuleController.cs in the Infrastructure.Module project:

If I were to load it up like a regular WorkItem and only use this code:

Then I would be loading it into the services for this module only, which is great, but I want this for all modules to use so I add it to my RootWorkItem. RootWorkItem is a property of any WorkItem that refers to the one and only root item created by the Shell. This way I know there's only one and I can access it from any module anywhere.

Once it's been added to the WorkItems list of Services, I can inject it into any module I need. I'll inject it into my presenter class as that's where I'll use it. The presenter will call the service to get it's values, and set the View with those values to update some GUI element (implementation of the View isn't shown but it just takes the values and binds them to a listbox or whatever you would use them for). I can inject it into the Presenter class two different ways. First, I can use the [ServiceDependency] tag in a parameter passed to the constructor of the Presenter:

Not that nowhere do I have to call the constructor, this is done with the AddViews method in the ModuleController and it knows that it needs a type of ILookupService to inject during construction. The constructor sets a private member variable of type ILookupService to the value passed in. ObjectBuilder knows it needs to get an object of that type and will find it using the ServiceLocator service, which is constructed by the Shell. The second way is I can set a property and decorate it using the [ServiceDependency] tag like so:

This is the same effect and is done whenever the object is created. Use one technique, not both as they'll both be called. Even though it's the same service object, it's just a waste to do it twice. Finally I just use the service in a method in my presenter when it's ready to update the view:

The end result is that I have a loosely coupled service that's injected into my presenter and provides my view with the services it needs. You can use either technique to set the service in the presenter and the great thing is that using something like Rhino mocks, you don't need to create the implementation of the service so writing presenter tests is a breeze with this technique, as you can setup whatever conditions you want for your tests.