Kent Boogaart

Paris

2008-07-22T16:01:00.001+01:00

Dirty. Expensive. Confusing. Those are words I would use to describe Paris.

Perhaps we were unlucky, but the neighborhood we stayed in (north-east of the city, near Gare du Nord station) was far from idyllic. The streets were paved in rubbish and dog crap, and we witnessed plenty of Parisians adding their own bodily fluids into the soup. Charming.

Eating out was nice enough, but really took its toll on the wallet. One place charged us €6.50 per beer! Of course, they didn’t tell us that until we’d finished drinking. And when we questioned the price, the manager was at the ready with a menu in hand. I suspect it was the specially-printed “tourist” menu.

As for getting around, it wasn’t too bad but was quite frustrating at times due to the strange layout of the city and the lack of good signs. There’s appears to be nothing consistent or logical about the geometry of the streets. It’s really kind of random.

It’s not all bad though. Central Paris was amazing. Notre Dame and The Louvre were a sight to behold (apart from the eyesore that is The Louvre Pyramid). The Eiffel Tower also looked great, but we didn’t get up close.

The second day saw us at Disneyland where rides and signatures are free, assuming your time and energy are worthless. Seriously – well over an hour to get Cinderella’s signature. By the time I reached her, she had changed shift and I got Snow White instead. I was heartbroken ;)

Tempany loved it all, though, which is the important thing.

The next day we went shopping. We were told to check out a local shopping center, and check it out we did. It was pretty good, and I picked up some shirts (€35 each, in case you were wondering). However, I was disappointed not to see more Asterix and Obelix merchandise.

The final day was a write-off, as we pretty much just hung around waiting for our train. Incidentally, Eurostar was great. Far less hassle than flying, and the difference in travel time is negligible.

I’ll probably go to France again one day, if only to see the Asterix and Obelix theme park.

Hawkeye

2008-06-30T14:38:00.001+01:00

Finally, it looks as though Hawkeye will be outed. It was always telling to me that suddenly we weren’t shown video replays of close calls anymore, only the Hawkeye simulation. I suspect if we were shown side-by-side replays all along then the technology would have proved to be inaccurate to the general public a lot sooner. Of course, it’s probably still more accurate than the human eye.

On the subject of tennis, we went down to Wimbledon last Friday. There was a nice five hour wait to get into general admission. Five hours in line with a three year old to see maybe the last hour’s play? Sure!

MAF Gymnastics: Service Provider

2008-06-18T09:32:00.001+01:00

Download the Solution

If you’ve ever worked on a composite application, you’ll know that services are their backbone. Services allow modules in the application to collaborate in both state and behavior. Moreover, services can be swapped out easily, since the modules work against an interface and are (hopefully) ignorant of the implementation behind the interface.

This post will address how to implement a service ecosystem using MAF in a composite application. In particular, how we can do this whilst keeping the host agnostic of the services it is hosting, and providing version tolerance for the services. Whilst I focus on composite applications, the techniques here can also be applied in non-composite applications.

Requirements

Agnostic Host

One of the challenges of implementing a service provider in MAF is ensuring that the host is capable of hosting any service, not just those services it knows about at compile-time. Without this ability, it’s not really a composite application and does not permit the kind of collaboration between add-ins that such an application requires.

Of course, the types related to the services must not be loaded into the host’s AppDomain. The services need to be isolated just like any other add-in.

Version Tolerance

Consider how composite applications are often written in the real world. You have a bunch of autonomous teams, each team producing and/or consuming services. Some teams consume services provided by other teams.

Then there’s the shell (aka “host”), which is responsible for hosting these modules and allowing them to collaborate. The shell is often produced by another team altogether to those producing the modules (aka “add-ins”).

Now think about what happens when one of the service-providing teams decides they need to modify their service interface. They can potentially break all the modules that depend on that service. In other words, the consumers of that service are at the mercy of the service provider.

MAF pipelines already provide a nice solution to this problem between the host and add-ins, but wouldn’t it be nice if the service provider could version their service over time, providing backwards compatibility as desired?

Solution

Add-in Types

The contracts define two types of add-ins: an application add-in and a service add-in.

At this point, the difference between a service add-in and an application add-in is minimal. A service add-in provides an ID by which it will be resolved by consuming add-ins.

Both add-in contracts have a common base interface (IAddInContract) from which they inherit an Initialize() method. Notice how this method returns an instance of AddInInitResult. This is crucial to the host being able to track which add-ins are hosted in which AppDomains.

The add-in views do not have this added complexity:

This is good, because the add-in developer need not worry about returning anything from their Initialize() implementation. Instead, this is handled by the adapters, as we’ll see later.

The host views mirror the contracts very closely, since the host does need to know and track this extra initialization information:

Add-in Activation and Tracking

When the host starts up, it first finds and activates service add-ins and then application add-ins. In both cases, it remembers the contract object for the add-in (that is, the MarshalByRefObject implementing the add-in). For services, it also maps the service ID back to the AddInToken so that it can obtain the contract implementation given only the service ID. This is important, of course, and you’ll see why soon.

Note that the tracking information is only actually necessary to support services, but the host code tracks application add-ins too, since that made the logic simpler.

The Host

It’s time to look at the pipeline components for the host. Firstly, the contract:

We’re getting closer and closer to the nitty-gritty now (I can’t believe that’s in the dictionary). The host contract has two methods of importance on it: GetPipelineDetails() and GetServiceDetails().

The former is quite simple: it just retrieves some basic information about the MAF pipeline. This information is needed by the add-in side adapters to support services. We’ll look at this further below.

The latter is also straightforward: it retrieves the service contract for a given service ID. Recall from above that when we activate services we track some information about that service. This method just allows the caller to retrieve that information.

The host view of the host is a mirror of the contract, so I won’t bother talking about it here. The add-in view of the host, on the other hand, is quite different:

As you can see, add-ins get a simpler view of the host. There is a single method that they can use to resolve a service by ID. There is no nonsense about getting pipeline information or what have you. The service consumer doesn’t care about that - she just wants a service.

I made this method generic just to save a little casting in the add-ins, but in reality I haven’t decided how I’d best like to compose this interface. I’m considering having the ID automatically determined by the interface type the service implements, so add-ins don’t even need to provide an ID. However, I haven’t spiked this yet so I don’t know if it will play out exactly as I hope. Anyway, I’ll be looking at that soon for a real project.

UPDATE: It works great! In my “real” project services do not need to explicitly provide an ID. Instead, the adapters infer it based on the view type the service implements. In addition, services are not explicitly requested from the host. Instead, the adapters determine the services an add-in requires by examining its Initialize() method and injecting any dependent services automatically. This results in a really nice, low-friction add-in development experience.

The Adapters

Based on the interfaces we just saw, you might assume that there’s some magic happening in the adapters to close the gap, so to speak. And you’d be right.

What we need to do is connect up the service consumer add-in to the service add-in, which already exists in its own AppDomain. Indeed, we may need to connect up multiple consumers to the service. Those consumers might be application add-ins or even other service add-ins (the sample only demonstrates the former, but the latter should work too assuming that the services are activated in the correct order).

Consider the following diagram:

The black lines represent the “primary” pipeline between the host and the add-ins, be they regular application add-ins or service add-ins. In the diagram we have a single service add-in (up the top) and two consumers of that service. The two consumers are built against different versions of the service (V1 and V2) but they both need to consume whatever version of the service is loaded (assuming the appropriate pipeline adapters can be found).

The service’s interface (ISomeService) extends the core service interface provided by the host (IService). Actually, this extension occurs in both the contracts and the views. As such, the service pipeline components depend on the pipeline components provided by the host. For the purposes of the primary pipeline, only the implementation of IService is used (that is, IServiceContract is used for communication over the black pipelines).

The blue lines represent the “secondary” pipeline between the service consumers and the service. It is this pipeline that provides marshalling specific to the service implementation (ISomeService).

And it is here where we need to employ some trickery to get the job done. First though, thanks to the anonymous commenter who pointed out an easier way to do this.

Here’s how it works. The add-in side contract to view adapter for the IHost interface implements the ResolveService<T>() method we saw above. In order to do this, it needs to construct a pipeline between the caller (ie. the consuming add-in) and the service itself.

The host’s AppDomain is impartial to this whole process – it merely provides some information the adapter needs to set up the pipeline. Once the adapter has this information, it uses MAF’s ContractAdapter type to adapt between the add-in’s view of the service and the existing service instance (ie. create the pipeline represented by the blue lines above). Specifically, the ContractToViewAdapter() method is used because we’re taking an existing contract (the service instance) and adapting it to the view.

Since the ContractToViewAdapter() method is generic and we don’t know the type until runtime, we need to invoke it reflectively. It might be nicer if MAF included non-generic overloads for these methods, but the fact that they’re public means that we do not need elevated privileges to invoke them via reflection. Thus, your add-in can still be hosted in a low-trust AppDomain.

Of course, once this pipeline is constructed we don’t need to do so again for the current AppDomain (unless a different view of the same service is used from within the same AppDomain, and the code caters for that case too). Therefore, we cache this information. Subsequent calls to ResolveService<T>() won’t even leave the caller’s AppDomain, which I think is pretty cool. Of course, calling into the service itself will marshal to the service’s AppDomain as expected.

Limitations

There are a couple of things you need to be aware of with respect to this technique. First and foremost, I mentioned above that MAF can only deal with one pipeline at a time. Further to this, it can only resolve one assembly from each pipeline folder. For example, all your add-in side adapters need to be in a single assembly inside the [Pipeline]\AddInSideAdapters folder. If your add-in side adapters assembly depends on another assembly, that assembly must be in the GAC in order for MAF to resolve it. MAF will not try to resolve that assembly from the same pipeline directory from which your add-in side adapters were loaded.

The problem with this is that the service pipelines depend on the host pipeline. As a simple example of this, the ISomeServiceContract included in the download extends the host’s IServiceContract. The upshot is that the host’s pipeline must be in the GAC.

In fact, this GAC registration requirement spreads virally throughout your pipeline projects. If you look in the sample you’ll see that most pipeline assemblies are registered in the GAC when you build. As such, you’ll need local admin since gacutil requires this. Unfortunately, I don’t see a way around this given MAF’s current architecture.

It’s important to point out that installing the pipeline components in the GAC is almost certainly what you want to do for deployments. Otherwise these assemblies cannot be shared between AppDomains and performance suffers badly. It’s just a shame that it’s also required for development.

Related to this issue is the possibility of name clashes in pipeline assemblies. You may have many teams working on services, and the pipeline assemblies for those services must reside in the same folder. Therefore, if one team chooses the same assembly name as another you will get a clash. This is pretty unlikely, but it’s something to keep in mind.

Less a limitation and more a “gotcha”: notice how the service implementation (in the Service project) references the service add-in views project (Service.AddInViews) and the service consumer add-ins reference the service host views project (Service.HostViews). In MAF terminology, the consumers are “hosts” of the service. This terminology doesn’t quite fit here because the consumers aren’t explicitly activating the service. In a real application, I would probably rename the service add-in views and host views to “provider views” and “consumer views” accordingly.

The Result

If you download and execute the sample you’ll see this:

As unexciting as this looks at first glance, it’s actually really, really cool. Trust me. What we’re seeing here is that there are four AppDomains:

One for the host
One for the service
One for the first service consumer
One for the second service consumer

The host and its pipeline know nothing about the specific service at compile-time. That is, it has no knowledge of ISomeService, only IService. And yet, it is hosting this service. That’s a check for an agnostic host.

The first service consumer is executing against version 2 of the service. It sets a value on the service to 26 and outputs the results of calling the service’s GetTimestamp() method. When it calls this method, it passes in a custom format string of “ddd MMM yyyy”.

The second service consumer is executing against version 1 of the service. It gets the value of 26 set by the first consumer and outputs it. Then it calls the service’s GetTimestamp() method and outputs that. But what’s cool is that version 1 of the service did not allow a custom format string to be passed into this method! The adapters for the service (see the Service.HostSideAdapters_V1toV2 project) are automatically using a default format string of “dd/MM/yyyy”. This proves that the correct pipeline components have been selected and used to join the service consumers to the service – that’s a check for version tolerance.

We have achieved everything we set out to achieve here. The host is agnostic of the services it will be hosting at runtime and none of the service types leak into the host. Moreover, the pipeline between service consumers and the service itself has all the intelligence you’d expect of a MAF pipeline. It selects the correct components to ensure that the service consumer can interact with the service, even if the consumer was built against an older version of the service.

Conclusion

Composite applications need a facility to provide and share services. An effective shell for a composite application needs to be agnostic of the services it is hosting, otherwise developers leveraging the shell are hamstrung by its intrinsic assumptions about the services it will host.

MAF’s concept of pipelines to handle version tolerance are equally applicable to services as they are to the shell itself. That’s simply because of the relationship between the provider of the deliverables and its consumers. As a shell or service developer, there is some uncertainty as to how many teams are leveraging your work, and how long they need to migrate to newer versions of your deliverables. Pipelines allow you to provide backwards compatibility so that consumers are not forced to update their code bases straight away.

The solution presented in this post solves both these problems. The shell knows nothing about the exact services it will be hosting at runtime. In addition, it uses a pipeline provided by the service developer to connect the service consumers to the service.

This was a particularly difficult topic to articulate, and I’m not confident that I did so well. If I failed to convey this information adequately, feel free to let me know in the comments and I’ll do my best to rectify the situation.

Download the Solution

MAF Gymnastics: Event Hub

2008-06-11T21:40:00.001+01:00

Download the Solution

The first problem I will attempt to address in this series is that of providing an event aggregator service (which I call an event hub, just to save on typing). That is, how can we allow add-ins to subscribe to, and publish events on a many-to-many event bus that is managed and implemented by the host?

When using MAF, there are a number of problems that must be solved in order to facilitate such a service. For one, how can we present a decent API to the add-in developer? The lack of generics support in MAF makes this difficult (see my previous post for details), and limits the overall effectiveness of the solution.

Next up, how can we ensure that event subject types (the CLR types that contain event payloads) do not leak into the host? If two add-ins communicate with a custom subject type, that type should not be loaded into the host's AppDomain. It should only be loaded into the AppDomain of those add-ins that care about that particular event.

With that in mind, how can we allow the host to use the event hub in much the same way as add-ins? That is, how can we design the host views such that the host can remain agnostic of subject types where necessary, but can publish and subscribe on the event hub where desired?

Finally, we'll discuss how the event hub service is exposed to add-ins. That is, how does an add-in actually obtain an instance of the event hub service.

The API

The contracts for the event hub service looks like this:

Importantly, you can see that there is nothing in these APIs that will cause types to leak from the add-in AppDomains to the host (or vice-versa). A string is used to identify subjects as opposed to a CLR type or RuntimeTypeHandle, both of which will result in errors because the corresponding subject type may not be available to the host. Also, subjects themselves are passed around as a byte array rather than an object instance. That allows the host to remain completely unaware of the actual CLR types involved.

The views for the event hub service look slightly different depending on whether you're an add-in or the host. For an add-in, the API looks like this:

The ISubscriber interface is what event subscribers must implement. It has a single method that is called when a relevant event is published on the event bus. The IEventHubService interface allows events to be published, and subscribers to be registered and unregistered.

A CLR type is used to scope events. That is, subscribers register their interest in events with a certain subject type. Subscribers will only receive events of types they have registered their interest in. In reality, you might want add-ins to just use a string to identify events. However, I wanted something that demonstrates how to differ your view from your contract.

This API is fairly clean and simple, but suffers from a lack of generics. Ideally, we would be able to define a generic ISubscriber<T> interface and have subscribers receive a strongly-typed subject argument. However, whilst the MAF pipeline does allow generic members in non-generic types, it does not allow generic types. That's because it must automatically hook up contracts and views with their corresponding adapters. If the contract or view is a generic type, MAF is not able to close the type (presumably because it does not have enough information to do so).

The API for the host is a little more complicated than that for the add-in:

The reason for the complication is that we want the event hub to be usable from the host in much the same way as it is from an add-in. To that end, we differentiate between two different subscribers: add-in subscribers and the host itself. There are basically two "modes" that the host-side works in: type-agnostic (add-in subscriber) and type-aware (host subscriber). The type-aware mode is not strictly necessary for the host to work with the event hub, but it sure makes it easier and consistent with the way the event hub works for add-ins.

The finally part of the API I want to draw your attention to is the IHost interface:

The EventHubService property on this interface is the means by which add-ins actually gain access to the service. In a later post I will discuss a more generalized and extensible way of exposing services to add-ins.

Adapters

The key to this solution is contained within the adapters. The adapters ensure that the host remains blissfully unaware of subject types and payloads. Consider this add-in code:

host.EventHubService.Publish(new CustomEventSubject() { Message = "Giggidy giggidy!" });

The add-in side view-to-contract adapter adapts this call such that the subject type (CustomEventSubject) is converted to a string used to identify the event, and the subject itself (the CustomEventSubject instance) becomes a byte array via standard .NET serialization. Neither parameter makes it unscathed into the host's AppDomain, which is fortunate because that would cause problems where the subject type was unknown to the host. The contract-to-view adapter does the opposite: it resolves a .NET Type instance based on the identifying string, and deserializes the byte array into an instance of the subject type.

If little alarm bells are going off inside your head right now after hearing about the automatic (de)serialization, it’s for good reason. I discuss why you should use the event hub service with care below.

Host

The host is largely untouched with respect to the skeletal solution. The one change is the use of qualification data to dictate the load order for add-ins. We need the subscriber add-in to load prior to the publisher add-in, otherwise the event publication will occur before there is a subscriber!

Each add-in has a QualificationDataAttribute applied to it to specify the load order. The host then uses the value in this attribute to order the add-ins prior to activation:

var orderedTokens = from token in tokens
                    orderby int.Parse(token.QualificationData[AddInSegmentType.AddIn]["LoadOrder"])
                    select token;

Note that this is just a simple fix for this specific scenario. A more real-world solution would be to allow one add-in to depend on another and order the activations accordingly. Perhaps I’ll address this in a later post.

When you execute the host, you should see something like this:

As you can see from the output, both the add-ins and the host are utilizing the event hub service. The add-ins are communicating with string subjects, and with a custom subject.

Deployment

Again, deployment hasn't really changed much compared to the skeletal solution. The one big difference is the Subjects project. This project contains a subject type that the add-ins use to communicate. Since both add-ins require access to this type, it must be referenced by each add-in and loaded into their AppDomain. Therefore, the build script for each add-in project copies this file to the add-in’s directory:

<Copy SourceFiles="$(OutputPath)\PublisherAddIn.dll;$(OutputPath)\Subjects.dll" DestinationFolder="..\Host\$(OutputPath)\AddIns\PublisherAddIn" />

Performance

Notably missing from the APIs is a filtering mechanism. That is, a way for publishers or subscribers to filter their interest in a particular event. I excluded this for two reasons:

It was too much effort for the purposes of this post, and would complicate things quite radically.
It would encourage cross AppDomain filtering, which is a potential performance issue.

Any event published to the event hub service has the potential to visit many AppDomains, so it should be used with care and only when necessary. If your add-in requires an event hub service, but it does not need to cross the AppDomain boundary (ie. it is internal to your add-in) you might instead consider something like this. To reiterate, the service discussed in this post should be used only when inter-add-in communication is required. Don’t use it for intra-add-in communications.

A Word of Warning

One thing you must be aware of before using this service is that it circumvents some of the measures MAF takes to protect you from versioning issues. Consider what would happen if you had a custom subject type that was consumed (subscribed to) by many add-ins. Suppose you wanted to alter that custom subject type and those alterations would break existing add-ins. You don’t have the luxury of using adapters to help out because the subject was never explicitly called out in the contracts. Instead, the best you can do is use built-in .NET serialization mechanisms (for example, OptionalFieldAttribute) to provide some compatibility, but this will be limited when compared to using a MAF pipeline.

Because of this, you want to be sure that any custom subject types you create are resilient to change. And when they must change, be sure to ensure that changes are backwards compatible (write some unit tests to verify). And if you simply cannot preserve compatibility, consider defining a new subject type altogether because the alternative is requiring every add-in be recompiled against the new version of the subject type.

Conclusion

An event hub service is imperative for applications where add-ins are required to communicate with each other in a loosely-coupled fashion. The solution I presented in this post allows you to achieve that even when add-ins are in completely separate AppDomains (or even processes) and the host has no knowledge of the types being used to communicate between the add-ins.

Limitations of MAF prevent us from providing an ideal solution - one that leverages generics to provide a strongly-typed API. However, this solution is still very workable. Just be cautious when defining subject types - you don't want them to become a versioning headache, especially considering MAF is designed to help prevent such headaches.

Download the Solution

MAF Gymnastics: Skeletal Solution

2008-06-08T12:55:00.001+01:00

To kick off this series of posts, I've put together a skeletal solution that will be used as a starting point for subsequent posts. MAF requires a lot of plumbing code and infrastructure to be in place before even the simplest example will work. As such, it is prudent for me to avoid duplicating much of that plumbing for each post.

If you download the solution, you'll see that it is comprised of quite a few different projects. Those projects are partitioned into solution folders.

Most of the projects are contained in the "Pipeline" solution folder. It is these projects that implement the pipeline that MAF uses to connect the add-in to the host. The "AddIns" solution folder contains any add-in projects (there is one sample add-in in the download). Finally, the "Host" project is a simple console host that activates any add-ins that it finds.

The Pipeline

The pipeline consists of a bunch of projects:

The Contracts project defines the contracts that MAF will load into both sides of the isolation boundary. It consists of a few simple contracts: IHostContract , IAddInContract and IApplicationAddInContract.

IHostContract provides some properties that add-ins can invoke to get information about their host (name and version, to be specific). IAddInContract defines a single Initialize() method that add-ins implement. This method takes an instance of IHostContract as a parameter, so the add-in can invoke members against the host. IApplicationAddInContract extends IAddInContract but does not add any members. In later posts I will have more than one type of add-in. IAddInContract will serve as a base contract for add-ins.

The AddInViews and HostViews projects define the view of the world for the add-in and host respectively. In this case, they mirror the contracts very tightly, but in later posts we'll see views that differ quite drastically from their corresponding contracts.

The AddInSideAdapters and HostSideAdapters projects provide adapters that MAF uses to adapt views to contracts and vice-versa. The adapters allow the view to be ignorant of the contract and vice-versa, which is required for supporting version tolerance.

Note that I have not used any code generation or tools to generate the pipeline. It is written entirely by hand. The reason I did not use Pipeline Builder is because it is simply not mature enough. I ran into many bugs and limitations when I tried to use it, and it does not give enough control over the generated code.

When I originally decided to ditch Pipeline Builder and write my pipeline by hand, I tried factoring out common adapter functionality into generic base classes. Unfortunately, MAF does not allow adapter classes to inherit from generic classes, even if the adapter itself is closed (I consider this an awful bug and have reported it as such). Moreover, common utility code for adapters cannot be placed into a separate assembly and placed into each adapter's folder because MAF will not load it (unless that assembly is placed into the GAC).

For these reasons, I had to jump through some hoops to factor out this code. Basically, if you look under the "Pipeline\Shared Code" solution folder you'll see some source code files. These files are then linked to from the adapter projects. In effect, the code is stored in one place (good for maintenance) but compiled into two separate projects (to appease MAF).

The utility code itself isn't as clean as it would be if MAF supported adapters with generic base types. However, it's still pretty straightforward. Adapters implement one of the two interfaces (IContractToViewAdapter<TContract> or IViewToContractAdapter<TView>) according to what type of adapter they are. From there, the static Adapt class can be used to convert views to contract and vice-versa. This cuts down on a lot of code repetition, but - again - not as much as I'd like.

The other option I had was to use a simple code generation tool. In a "real" project I would probably do exactly that, but I didn't want to complicate these examples.

The Add-in

Included in the solution is a very simple add-in that simply outputs some information when it is initialized by the host (via the Initialize() method):

[AddIn("Sample add-in")]
public class AddIn : IApplicationAddIn
{
    public void Initialize(IHost host)
    {
        Console.WriteLine("This is the sample add-in, running inside host with name '{0}', version {1}. AppDomain name is '{2}'.", host.Name, host.Version, AppDomain.CurrentDomain.FriendlyName);
    }
}

As you can see, it outputs the details of the host (name and version) and the name of the AppDomain in which it is running (to prove we're being hosted in a separate AppDomain).

The Host

The Host project is a console application that activates and initializes any add-ins it finds that implement the IApplicationAddIn interface. The most pertinent code is contained in the Host.Run() method. This is the code that updates the add-in store, finds and activates any add-ins, and then initializes them.

When you execute this project, you should see something like this:

Deployment

MAF has strict requirements on how the pipeline and add-ins are deployed. If you've read through the MSDN documentation, you'll see recommendations on creating a solution-level output folder and deploying all DLLs within there. I don't like this recommendation because it's non-standard and doesn't deal with multiple configurations (although you could have output\Debug and output\Release folders).

In order to remain somewhat standard and not cause too much confusion, my solution builds into the output folder of the Host project, as you'd expect. Under bin\Debug (or bin\Release) you'll find directories called Pipeline and AddIns. Pipeline segments and add-ins are automatically copied to these directories when you build the solution.

If you're wondering how these files are copied, take a look in one of the project files. For example, crack open the SampleAddIn.csproj file and you'll see this at the end:

<Target Name="AfterBuild">
    <Copy SourceFiles="$(OutputPath)\SampleAddIn.dll" DestinationFolder="..\Host\$(OutputPath)\AddIns\SampleAddIn"/>
</Target>

Conclusion

Well, this has turned into a long post - and we haven't even started yet! MAF is a complex beast - incredibly frustrating at times, and yet very rewarding at others. Hopefully I have set the stage for the subsequent posts, where I will look at how some specific application scenarios can be addressed in MAF.

MAF Gymnastics: Prologue

2008-06-05T19:59:00.001+01:00

The Managed Add-in Framework (MAF) was introduced in .NET 3.5. In short, it is a framework that aims to ease the burden of supporting an add-in ecosystem within your application. It provides features around add-in discovery, loading, and isolation.

The benefits of a good add-in model include:

Security. Add-ins can be isolated and sand-boxed, each with its own set of permissions.
Stability. Isolation also means add-ins have a limited ability to affect each other. If one add-in fails, it does not necessarily affect other add-ins. In addition, it is often possible to switch add-ins from AppDomain isolation to process isolation, which affords even more stability.
Version tolerance. The host application can version independently of add-ins. If the host is developed with care, an add-in written against version 1 of the host can still work against version 2 of the host.
User experience. With add-ins isolated into separate .NET AppDomains, it becomes possible to load and unload add-ins without requiring the host application be restarted.

The key to achieving these benefits is AppDomain isolation. Without it, most of these benefits cannot be realised (version tolerance is the exception). However, supporting AppDomain isolation in your application and add-ins is no walk in the park. It introduces a slew of complexities that will have you tearing your hair out in no time.

This series of blog posts addresses some MAF scenarios that I believe are quite common, but have not so obvious an implementation. I haven't finalized the set of scenarios I'll be covering, but I have two written, with a further two in mind.

Note that I do assume the reader has a fundamental understanding of MAF throughout this series. If you're just getting started with MAF, you should check out this section in MSDN and read this series later.

In the next post I'll provide a skeletal MAF solution which we'll be using as a starting point for subsequent posts.

PS3 Power Consumption

2008-06-04T19:35:00.002+01:00

From this article:

Our tests found that leaving a Playstation 3 on while not in use would cost almost... five times more than it would take to run a refrigerator for the same yearly period

And, in response, I have this to say:

Yep, that's my PS3 power consumption in standby. A massive 4 watts. And, in comparison, here is my microwave in standby (I can't reach my fridge socket):

All I can think of is they measured with wireless on, which may consume more power, but if they at least published specifics that would be helpful. I couldn't track down the supposed original article on choice.com.au.

UPDATE: Nope, just tested and even with wireless on it still uses a measly 4 watts when on standby.

UPDATE 2: OK, I tracked down the original article. It's here. It turns out they were misquoted in the yahoo post. The incorrect quote is "an Australian consumer agency study has found that videogame consoles ... are major electricity guzzlers, even when left on stand-by". However, the article itself points out that you should put consoles on stand by when not in use. Wow, revolutionary advice. Who the hell would leave a console on when they're not playing it? That's like leaving the TV on and muting it when you're not watching it. Newsflash: refrigerators are designed to be on 24/7; consoles are not.

Gauntlet V1 Released

2008-05-18T17:53:00.001+01:00

Today I released V1 of Gauntlet, which is a .NET code generation tool that integrates seamlessly into your build process. I've been working away at it on and off (mainly off) for a few months now, so it felt somewhat therapeutic to finally release it.

There are a wide variety of uses for Gauntlet, but here are a couple of examples:

Gaining control over the proxy classes generated for web / WCF services
Generating large parts of your domain / business layer
Generating constants or enumerations from sample data

Head on over to the Gauntlet CodePlex site for more information.

Expander and VisualBrush

2008-05-15T19:47:00.001+01:00

Today I was trying to implement some drag and drop spiffiness by including a semi-transparent preview of the item being dragged. Basically when the user starts dragging something, it "tears off" and follows the mouse cursor, so they can see exactly what they're dragging. Like I said: spiffy. Don't deny it.

Sounds like a job for VisualBrush, and indeed it is. I was able to get this working pretty nicely, but noticed a weird problem with Expanders. Basically, if you expand and then collapse an Expander, and then use a VisualBrush to clone it, the VisualBrush will clone both the header of the Expander, and the white space the Expander previously occupied when expanded.

Huh?

Let me explain with pictures. Say you've got an Expander:

And you then expand it, and subsequently collapse it:

Then then your code creates a VisualBrush around the Expander like this:

Rect rect = new Rect(0, 0, _expander.RenderSize.Width, _expander.RenderSize.Height);
VisualBrush visualBrush = new VisualBrush(_expander);
_rectangle.Fill = visualBrush;

What you get looks like this:

What the...? What's happened here is what I described above. The size of the Rectangle hosting the VisualBrush is correct. However, the snapshot the VisualBrush has taken of the Expander is incorrect because it includes white-space below the header, even though the Expander is collapsed.

As I discovered, other people have come up against this problem too, but no solution was apparent. Thus, I set about to find one.

And here it is:

Rect rect = new Rect(0, 0, _expander.RenderSize.Width, _expander.RenderSize.Height);
VisualBrush visualBrush = new VisualBrush(_expander);

visualBrush.ViewboxUnits = BrushMappingMode.Absolute;
visualBrush.Viewbox = new Rect(_expander.TranslatePoint(rect.TopLeft, this), rect.Size);

_rectangle.Fill = visualBrush;

This time we get the expected result:

The trick is to use absolute units for the view box, and to translate the Rectangle relative to the host. This doesn't really explain the bug, but it does work around it. You can download the sample project (pictured in the images above) right about here.

Dispatcher Frames

2008-04-28T20:09:00.001+01:00

With scant exception, WPF controls must be accessed from the same thread on which they were created. Because of this, we say they have 'thread affinity'.

In WPF, thread affinity is realised via DispatcherObjects, which can be accessed directly only on the thread on which they were created. Alternatively, they can be accessed via their Dispatcher. The Dispatcher contains methods for adding operations to a queue which is processed on the Dispatcher's thread. Each thread has at most one Dispatcher instance associated with it (which is created on demand). Many WPF classes - including controls such as TextBox and Button - inherit from DispatcherObject. This means that accessing instances of these controls must be done on the control's thread, possibly via the control's Dispatcher.

You may have noticed a type called DispatcherFrame whilst browsing MSDN (as you may be inclined to do on a Saturday night. Or not). That's what I want to discuss in this post.

You can think of a DispatcherFrame as something that forces operations to be processed until some condition is met. Every WPF application has at least one DispatcherFrame that is created when you run the application. It will continue pumping operations until the application is shut down.

At times it can be useful to pump operations until some condition of your own is met. Perhaps your code is executing on the UI thread and you want to empty the queue of operations in the Dispatcher to force control and screen updates. In the Winforms world, this is achieved via a call to Application.DoEvents(). In WPF, there is no equivalent method, but we can easily simulate one:

public static void DoEvents(this Application application)
{
    DispatcherFrame frame = new DispatcherFrame();
    Dispatcher.CurrentDispatcher.BeginInvoke(DispatcherPriority.Background, new ExitFrameHandler(frm => frm.Continue = false), frame);
    Dispatcher.PushFrame(frame);
}

private delegate void ExitFrameHandler(DispatcherFrame frame);

The above code is part of a small demo project, which you can download here. It adds a DoEvents() method to WPF's Application class. The DoEvents() method adds a Background priority operation to the Dispatcher's queue, and then pushes a new frame that pumps operations until that operation is processed. As a result, all other operations that were already queued in the Dispatcher will be processed. There are several important things I need to point out here:

1. Adding the new operation to the Dispatcher is done asynchronously. As such, the operation is not processed until we call PushFrame().
2. The choice of Background as the priority is important. If we were to choose a higher priority (such as Render), then we would potentially leave lower-priority operations in the queue after the frame had exited. That's because our operation would be executed prior to those lower-priority operations, and thus we'd end the frame too soon. Perhaps there's value in adding a DoEvents() overload that accepts a minimum priority of operations that should be executed, but I haven't included one in the download.
3. Operations in a Dispatcher are not associated with a particular DispatcherFrame. A DispatcherFrame can cause any queued operation to be processed, not just those added after the frame is pushed.
4. The code assumes it is running on the thread whose Dispatcher should be pumped.

A DoEvents() implementation is nice for illustrating the utility of DispatcherFrames (indeed it is used in the MSDN documentation too), but I believe it is unnecessary. As you can see in the demo, it is possible to simulate DoEvents() in a much simpler fashion: by synchronously adding a low-priority no-op to the Dispatcher's queue:

public static void DoEvents(this Application application)
{
    Dispatcher.CurrentDispatcher.Invoke(DispatcherPriority.Background, new VoidHandler(() => { }));
}

private delegate void VoidHandler();

The call to Invoke() will not return until our operation has been processed, which won't be until all higher priority operations are processed. Therefore, the end result is the same - all queued operations are pumped (apart from those with a priority lower than Background, but I'm ignoring that in this post).

So where would you use a DispatcherFrame?

I recently had need for one at my day job. We have a splash screen that usually just shows progress information (downloading files, searching for modules etcetera) but sometimes needs to ask the user which catalog they would like to load (a catalog is just a set of modules).

The splash presenter tries as hard as it can not to ask the user (if they only have one catalog, or it has been specified via a command line switch then it doesn't need to ask), but if it does need to, it delegates a call to the splash view on the UI thread. This call needs to return the catalog that the user selected. However, it has been called on the UI thread, so obtaining a catalog from the user requires pumping operations so they can select one from a list. The code looks like this:

public Catalog SelectCatalog(ICollection<Catalog> availableCatalogs)
{
    StatusLabel = "Please select a catalog:";
    _catalogsItemsControl.ItemsSource = availableCatalogs;

    _catalogSelectionFrame = new DispatcherFrame(true);
    Dispatcher.PushFrame(_catalogSelectionFrame);


    StatusLabel = "Thank you"; 
    _catalogsItemsControl.ItemsSource = null;

    return _selectedCatalog;
}

This method sets up the catalogs for the user to select from by assigning them to an ItemsControl (which renders each catalog as a hyperlink). It then pushes a new DispatcherFrame, which blocks until the frame is stopped. After the DispatcherFrame finishes, the selected catalog is returned. The only way to end the frame is by clicking on one of the hyperlinks representing the catalogs. Each hyperlink rendered by the ItemsControl has a Click handler as follows:

private void _hyperlink_Click(object sender, EventArgs e)
{
    _selectedCatalog = (sender as Hyperlink).DataContext as Catalog;
    _catalogSelectionFrame.Continue = false;
}

When a hyperlink is clicked, I store the selected catalog and then end the DispatcherFrame. As a result, the code that pushed the DispatcherFrame will continue execution. Note that I would not have to manually track the selected catalog if I was using a ListBox, but for now I'm using with the ItemsControl because it was simpler to style.

Above I suggested that the only way to end the DispatcherFrame was by setting DispatcherFrame.Continue to false. That's not the entire story. DispatcherFrames may also be asked to stop during application shutdown. When that happens, DispatcherFrames will, by default, comply with the request. However, there is a constructor overload that allows you to bypass this behaviour and instead continue processing operations until your condition is met. This might be useful for a short-lived frame whose completion is critical to the correctness of your application.

Download Demo

Berlin

2008-04-19T12:51:00.001+01:00

Last weekend we headed to Berlin. We stayed south-east of the city, in the appropriately-named Holiday Inn. Friday night was basically a write-off, since we didn't arrive until around 10PM. On Saturday we had a late breakfast and then headed into the City.

Unfortunately, the S9 line which connected us to the centre of the city was under weekend maintenance, so it was a time-consuming process getting anywhere. This is one of the train stations we waited at (Betriebsbahnhof Schöneweide):

Eventually we made it into the city and headed to the Berlin Zoo, which was fantastic:

(poor photo, but I just love black panthers. All cats want to be them)

On Sunday we wanted to visit Fernsehturm, which is a 365 metre high tower in central Berlin. After waiting for 40 minutes or so, we gave up because the line wasn't moving. However, here are some pictures of the tower:

The people in Berlin were very nice, and the weather was perfect. Overall it was a great weekend, although we would have liked more time to fully appreciate it.

SCSFContrib 1.5

2008-04-18T18:19:00.001+01:00

Admittedly, it has been far too long, but the SCSFContrib team have finally released version 1.5. The highlights of this release are:

New Features
- All solution and projects migrated to Visual Studio 2008 and .NET Framework 3.5.
- DockPanelWorkspace and FormWorkspace added to SCSFContrib.CompositeUI.WinForms project.
- Action Catalog Service added to SCSFContrib.Services project.
- Added Visual Studio templates and Installer for Trusted and Untrusted modules in the WPF/CAB Shell.
New Samples
- BankTeller implementation using a pure WPF application.
- Demo Application with its Demo Script that provides step-by-step instructions to create a SC-SF application.
- OrdersManager application that demonstrates how to integrate the CAB and SC-SF with Windows Workflow Foundation.
- TestSuite reference application showing DockPanelWorkspace usage.
- WPF CAB Shell sample application (source code, libs and unit tests).

You can head over to the SCSFContrib CodePlex site to download. Enjoy!

How to Waste 3 Hours on a Wednesday Afternoon

2008-04-02T20:26:00.001+01:00

I'm playing around with the new to 3.5 System.AddIn stack at the moment. In short, it allows you to provide version tolerance between components. This is commonly used in with add-ins.

Anyways, the thing that sits between the host and add-ins is called the pipeline. It consists of a bunch of assemblies - a host view, host adapter, contracts, add-in adapter and add-in view. If the stars are aligned and the gods bestow you with grace, you will eventually get these assemblies to work.

Experiencing this pain, you may look to Pipeline Builder, a tool that helps to generate the views and adapters from the contract. That's what I did anyway. But I found that the lack of control over the generated code was causing me headaches (using templates would be nice), and the limitations of the tool mean that you'll end up with some generated code and some manually written. This wound up being way too painful to troubleshoot and maintain and I'd rather just have full control over the code for now.

Sound like a plan, Stan? Since I was taking full control over the code I thought I'd go the whole hog and refactor common functionality into helper classes. Instead of an adapter that looked like this:

public class IAddInContractToViewAddInAdapter : Contracts.AddInViews.IAddIn
{
    private Contracts.IAddInContract _contract;
    private System.AddIn.Pipeline.ContractHandle _handle;
    static IAddInContractToViewAddInAdapter()
    {
    }
    public IAddInContractToViewAddInAdapter(Contracts.IAddInContract contract)
    {
        _contract = contract;
        _handle = new System.AddIn.Pipeline.ContractHandle(contract);
    }
    public void Initialize(Contracts.AddInViews.IHost host)
    {
        _contract.Initialize(Contracts.AddInSideAdapters.IHostAddInAdapter.ViewToContractAdapter(host));
    }
    internal Contracts.IAddInContract GetSourceContract()
    {
        return _contract;
    }
}

After a bit of refactoring, I ended up with this:

public class ContractToViewAdapter_IAddIn : ContractToViewAdapterBase<IAddInContract>, IAddIn
{
    public ContractToViewAdapter_IAddIn(IAddInContract contract)
        : base(contract)
    {
    }

    public void Initialize(IHost host)
    {
        SourceContract.Initialize(Adapt.ToContract<IHost, IHostContract, ViewToContractAdapter_IHost>(host));
    }
}

Nice. The ContractToViewAdapterBase<TContract> class provides all the functionality around exposing the source contract and maintaining the ContractHandle. I also have a generic Adapt class that takes on the task of converting views to contracts and vice-versa. The Pipeline Builder generates a separate class for every contract - yuck.

Once I had taken complete control of the code I managed to reduce it in size and complexity significantly. Problem is, it didn't work. All I got was this warning:

No usable HostAdapter parts could be found in assembly "...HostSideAdapters.dll".

Um, right. My host adapter was definitely in the assembly and definitely marked with the HostAdapter attribute. So what was going on?

System.AddIn does its very best to make your life a living hell when something doesn't work. There's no trace statements, meaningful exceptions are suppressed, and if you're lucky enough to get a warning message it's usually cryptic and unhelpful. Oh, and the source and symbols for System.AddIn are not available yet, so you're on your own there, too.

After pulling some hair out I managed to figure out why my adapters weren't being found. It's because they inherit from a generic type. Yep, that's right. Even though the adapter itself is a closed type, System.AddIn spits it because I inherited from a generic type. Worse, it swallows a resultant GenericsNotImplementedException that gets thrown internally.

I got rid of the generic base class and instead implemented the corresponding generic interface manually. Now my adapters have more code in them and are harder to maintain. Stellar.

I realise this post comes across as a jab at System.AddIn. Actually, for the most part I really love the possibilities this stack yields. It just needs a lot of attention, especially in the area of diagnostics.

I've posted an issue report here.

PS3

2008-03-30T15:03:00.001+01:00

As a follow-up to my previous post, I bought the PS3. There were just too many positives to ignore. I got it together with Gran Turismo 5 Prologue for £300, which seemed pretty reasonable. I had to buy an HDMI cable separately, given that it doesn't come with the system. Maybe they should just ship with no cables, so consumers can save money buy getting only the cables they need.

The setup experience was seamless. I plugged the four cables in (HDMI, Ethernet, power and USB to charge the controller) and turned it on. Once I figured out how to switch my TV to HDMI input, the PS3 setup wizard was sitting there waiting for me. And - wow - did it look beautiful. Even simple text with a background animation was looking incredibly clear in HD. The setup process was straightforward and I was good to go in a couple of minutes.

Once the setup was done, the first thing I did was upgrade the firmware. This was a simple matter of going into the system menu and telling it to upgrade via the Internet. Then I sat back and waited while it upgraded the firmware from 2.01 to 2.2.

Once done, I explored the menus a little and made sure everything was configured as I expected. In doing so, I was delighted to learn that there is Bluetooth support in the PS3. That will come in handy for audio during the late-night gaming sessions, since I already own some Bluetooth headphones.

The thing that really struck me as I was looking around the menus was how fluid, intuitive and responsive they were. This is in contrast to the 360, where I often have to stare for a half second or so to comprehend which tab I'm looking at, and switching between tabs felt too slow. Someone has already recorded the PS3 menu experience here, and it's well worth a look if you haven't used a PS3 before.

The next thing I did was play some GT5. To be honest, I never liked the GT franchise because everything is so realistic . . . except crashing. It really kind of spoilt the games for me. You'd be caught up in the realism, only to hit a barrier at 200Kmph and bounce off it like you were playing bumper bowling or something.

That said, everything else about the game is outstanding. I played it a lot yesterday and plan on getting back on ASAP today (it takes a lot of willpower to write a blog post on the couch with the PS3 and TV both staring at me). I'll also be buying COD4 during the week, and jumping on GTAIV as soon as it arrives.

At some stage yesterday, I jumped on to some multi-player GT5 too. Again, everything just worked and in no time at all I was racing against people with approximately the same driving skill as myself (ie. very little).

Next up, I tried out the built-in web browser. I found it really quite usable. The lack of a keyboard (I haven't plugged in my USB keyboard yet) can make URI entry painful, but viewing pages and moving between links is really quite a good experience. You can zoom and pan with the controller, as well as move between links just by using the D-pad. All in all - good stuff.

Finally, I wanted to try out the media functionality. Remember, this is the main reason I purchased this system - to access my media. At first I found the interface a little confusing. There are top-level menu items for photos, music and video. If you go to the music menu, for example, you'll still see all folder served up by the media server, which for me includes 'Videos' and 'Photos'. Navigating into these folder just gives you a message of 'There are no tracks'. Well of course there are no music tracks in my 'Videos' directory.

I'd like to see this segregated media experience conglomerate into a single menu item: 'Media'. From there I'd like to be able to drill into specific media types or even search across my entire media library (using tags would be awesome!). For example, I could search across all media for 'London' and find all my London photos and videos (but also find London Bombs by Eskimo Joe, unless I choose not to search my music media). Hopefully this experience is fixed up a bit in a future firmware release.

I was able to view photos and listen to music straight off the bat. Awesome. However, when I tried watching video media I got a 'Media unsupported' or some such message for every video file I tried. Hmm, odd. Given that I was on firmware 2.2, all these videos should have been working. Therefore, I suspected it was an issue with my home server rather than the PS3. I tried copying those same files onto USB flash and playing directly from that stick. Doing so worked fine.

It turns out that Windows Home Server comes with Windows Media Connect 2.0, which is outdated and doesn't support DivX or Xvid. Therefore, I'd need to install Windows Media Player 11 on my WHS box in order to stream these videos to my PS3. Fair enough, but it wasn't exactly obvious how to do this because the WMP11 installer does not allow you to install on WHS. I found this thread (and specifically the post by cigga24) on the MSDN forums that lead me through the process of getting this to work. 10 minutes later I had WMP11 installed on my WHS. I tried playing the same videos on my PS3 and - lo and behold - everything worked perfectly! Moreover, the PS3 is deathly quiet, so it's a great solution for a media hub.

I'm still not a huge fan of the PS3 controller, although I have adjusted to it a little over the past day or so. I like the analog triggers on the 360 controller, especially for car games. Ideally, I'd like a 360 controller for the PS3. I see someone has already hacked this together, but this only works inside a linux installation on the PS3 not inside games. In other words, it's pretty much useless.

I haven't tried out the Blu-ray player yet. I think next weekend I'll hire Apocalypto and check it out. I have no doubt it's going to be awesome.

All in all, I'm extremely pleased with the PS3 so far. There are a few interface improvements I'd like to see, but hopefully they will be fixed with a little time. I'm also going to experiment with a linux installation and geek out a bit there.

Alright, enough typing. I'm going to play some GT5...but first, thanks to everyone for the comments in my previous post. They were very helpful indeed.

PS. I would post a picture but everything is a mess at the moment. I'm waiting for a proper TV stand, after which I will be able clean everything up.

Cardiff

2008-03-30T13:14:00.001+01:00

A couple of weeks back I went to Cardiff with some Infusion mates (or 'buddies', as most of them would say). We went to see Wales kick French butt in the rugby final. The weather was crap, but the company and atmosphere was A+. We started early and finished late. A good time was had by all (minus the French).

I didn't post the pictures back then because - at first glance on my dinky camera screen - they looked as though they hadn't turned out. But yesterday I saw them in glorious 1080p HD via my new XBox / PS3 (I'm not telling which one I bought yet. Not sure why - I just enjoy a bit of manufactured suspense, I guess :D ). Some of the photos had actually turned out quite well, so here goes:

(Cardiff castle - I think)

(the bar was a little crowded)

(the trip back, where most everything looked like a bed)

A White Easter

2008-03-23T21:09:00.001Z

Well, it was a little white, but mostly just damn cold:

Happy Easter! And believe it or not, that's Vegemite on Tempany's face - not chocolate.