This is the introduction posts about dynamic client / server localization which describes the problem domain. In one of my current projects, we are building a client / server application that uses windows communication foundation requests and responses and event driven data, which is fired over the distributed event broker. Some of the data is dynamically rendered on the client but needs to be translated into several languages. For information which is already known at compile time localization is really straight forward with WPF. But what about data which is not known at compile time of the client?
.NET
bbv.Common, Distributed Event Broker, Localization
Implementing the dispose pattern according to IDisposable can be very tedious. Why not simply use the new Lazy<T> to get rid of some boiler plate code? The trick is to define a Lazy<Action> with a function delegate which calls a release method. As long as you don’t access the value property of the lazy type the release method is not called. Lazy<T> offers the possibility to check whether the underlying value has been created or not (property IsValueCreated). Therefore we can use this to check whether we already disposed the underlying resources. Let’s see how this looks like in code:
public class SomeDisposable : IDisposable {
private Lazy<Action> dispose;
public SomeDisposable() {
this.dispose = new Lazy<Action>(() => this.Release);
}
public void Dispose() {
this.Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing) {
if (disposing && !this.dispose.IsValueCreated) {
this.dispose.Value();
}
}
private void Release() {
this.resource1.Dispose();
this.resource2.Disconnect();
this.resource2.Dispose();
}
}
Remarks: I left out the finalizer to not clutter up the code sample too much.
Happy lazy coding!
.NET
Dispose, Lazy
The reporting mechanism allows creating a full report of the bootstrapping process. To be able to report the bootstrapping process the process must actually run and a reporter must be present. By default the bootstrapper uses a null reporter which does nothing with the report. But it is also possible to hook in a report generator which creates Visio, Enterprise Architect or … (you name it!) diagrams.
A custom reporter must implement the reporter interface IReporter. The reporter receives an IReportingContext which contains all necessary information about the bootstrapping process. The custom reporter must be passed upon the construction of the DefaultBootstrapper<TExtension>.
.NET
bbv.Common, bbvcommon, bootstrapper
Configuration sections
The bootstrapper supports loading of configuration sections through behaviors. The behaviors responsible for loading configuration sections must be applied in the begin section of the run syntax.
ConfigurationSection
To be able to load configuration sections the ConfigurationSectionBehavior must be added in the strategy.
.NET
bbv.Common, bbvcommon, bootstrapper
Strategy
The strategy defines the order of execution for extension points and behaviors. The custom strategy must inherit from IStrategy. For convenience, use the provided abstract base class AbstractStrategy{TExtension} which simplifies defining a custom strategy. The strategy could look like the following:
.NET
bbv.Common, bbvcommon, bootstrapper
Here is a draft of my xUnit Cheat sheet
Update: 06.12.2011, added IUseFixture<>
xUnitCheatSheet (Currently V0.2)
Let me know if you have any updates…
.NET, Test Driven Development, Testing
cheatsheet, Xunit
Behaviors
Behaviors allow extending the bootstrapping process in an aspect oriented style. Behaviors gain access to extensions which are participating in the bootstrapper process and can therefore influence them for example by injecting additional runtime information into an extension. Behaviors must implement IBehavior<TExtension>. They automatically gain access to all extensions participating the bootstrapping process. Behaviors are executed before the corresponding extension point is called.
.NET
bbv.Common, bbvcommon, bootstrapper
Advanced
The bootstrapper can do more! Let us look into a more complex scenario. Often it is required to collect context information during the bootstrapping process and pass this information to the extension points.
Imagine you are using an inversion of control container which intakes IModule implementations to register dependencies during the bootstrapping process. All IModule implementations need to be passed into the IContainer implementation upon construction. For backward compatibility the bootstrapper must automatically check whether an extension implements IModuleProvider and register the provided modules on the IContainer implementation.
.NET
bbv.Common, bbvcommon, bootstrapper
Introduction
To get started with the bootstrapper you need the following three things:
- Extension interface
- Strategy
- Bootstrapper setup
Extension interface
The extension interface defines the extension points which are called by the bootstrapper. The custom extension interface must inherit from IExtension and can only declare methods which return void as extension points. A very basic extension interface could look like the following:
public interface ICustomExtension : IExtension
{
void Start();
void Stop();
}
.NET
bbv.Common, bbvcommon, bootstrapper
Urs started with the idea and the category “why I like”… So I’ll steal his idea and go further with this category… This might be an expensive blog post because I need to pay license fees to Urs 
We adopted machine.specifications for our project approximately one year ago. We compared several context and specification frameworks but the overhead of the competitors was too high for our team. Also didn’t we have a product owner who was willing to write for example Gherkin language. So we decided to go with the developer centric machine specification from Alexander Gross.
.NET, Why I like ...
Machine.Specification, MSpec
