Mr Andersson

Posts Tagged ‘ioc

Deploying applications to Windows and Windows Phones which supports dynamic modules

leave a comment »

Many .Net applications being developed today are leveraging the greatness of dependency injection using some sort of inversion of control-container. So do we at RemoteX when we develop the product called RemoteX Applications. The product has two client applications which roughly adresses the same use cases. One is targeting desktop computers and the other one is targeting Windows Phone (you can read more here and here).

As you can tell by the name, the product consists of several applications (or rather modules). Using frameworks like Prism or Caliburn we can, in code, easily manage each part of the product. And the deployment is taken care of using ClickOnce technology using mage.exe (the MAnifest GEnerator).
But that’s for the desktop client targeting WPF.

So the big question is, how are we going mobile with this?

What regards an inversion of control-container we are “almost there”. We have a home-grown container in place which have been around for a while now, even though it lacks some basic features you would expect an ioc container of year MMX to have.
Speaking of deployment to the Windows Phone you probably know you are kind of locked to using CABinet files. If you are using the tools Microsoft brought to us, you probably also use their Device Setup projects in Visual Studio.
They are good, but you must use Visual Studio to choose the contents of and create/build your CAB file.
What this basically means is that we need to use devenv.exe to build each customer’s customized CAB file.
So up til now we have not had per customer customized CAB files.

All I wanted was ClickOnce technology and a manifest generator for the Windows Phone. So what’s the solution on that?
Say hello to the PowerShell script New-CabWizInf.ps1:

.\New-CabWizInf.ps1 -path .\myapp.inf -appName “My Application” -manufacturer “RemoteX” -fromDirectory .\MyApplication\bin\Release

It works like mage.exe with its -fromDirectory switch and creates the necessary .inf-file (like an Visual Studio Device Setup project would). All needed from that point is to call CABWIZ.exe and Set-AuthenticodeSignature in PowerShell to create and sign the CAB file.
The real power is the -fromDirectory switch which allows us to create custom CAB files on the fly.

So here is a peek of what our setup package scripts now looks like:

Setup Package for Windows using ClickOnce
mage -new deployment -tofile MyApp.application -fromdirectory bin\Release -name “My App” -publisher “RemoteX”
mage -sign

Setup Package for Windows Phones using CAB files
.\New-CabWizInf.ps1 -path MyApp.inf -fromDirectory bin\Release -appName “My App” -manufacturer “RemoteX”
cabwiz MyApp.inf /dest .\
Set-AuthenticodeSignature .\MyApp.CAB

So right now I’m a very happy camper since our packaging tools for Windows AND Windows Phone have equal capabilities which allows us to use dependency injection with dynamic module selection.

Next stop, Prism and Silverlight for the Windows Phone?

Written by anderssonjohan

January 20, 2010 at 23:28

Posted in software

Tagged with , , , , ,

Switching component implementations in Castle Windsor

leave a comment »

Problem: Test suite for a system for which I need to replace (inject) the behavior of a certain component. The system is using Castle Windsor with an XML configuration file.

In this system integration test I want to use the real container configuration except that I want to switch out a component that does authorization using a database.

The replacement for the real component is as simple as:

public bool IUsernamePasswordVerifier.VerifyPasswordFor( string username, string password )
return true;
Solution: Tried this, which failed on me. But with a little help from a tiny facility used by the test suite I can now “re-wire” service implementations in the container.
There are probably several other solutions on how one could accomplish the same thing, but this one worked out very well for me.


using System;
using System.Collections.Generic;
using Castle.Core;
using Castle.Core.Configuration;
using Castle.MicroKernel;

namespace ServiceTests.Service
public class ComponentRewriteFacility : IFacility
readonly IDictionary<Type, Type> _rewrites;

public ComponentRewriteFacility()
_rewrites = new Dictionary<Type, Type>();

public void AddRewrite<I, T>() where T : I
_rewrites.Add( typeof(I), typeof(T) );

public virtual void Init( IKernel kernel, IConfiguration facilityConfig )
if( kernel == null )
throw new ArgumentNullException( "kernel" );
kernel.ComponentRegistered += ComponentRegistered;

public void Terminate()

void ComponentRegistered( string key, IHandler handler )
if( !ShouldRewrite( handler.ComponentModel ) )
handler.ComponentModel.Implementation = _rewrites[handler.ComponentModel.Service];

protected virtual bool ShouldRewrite( ComponentModel componentModel )
return _rewrites.ContainsKey( componentModel.Service );

And in our test suite initializer we add the “re-write rule” like this:

IWindsorContainer container = new WindsorContainer();
container.AddFacility<ComponentRewriteFacility>( f => f.AddRewrite<IUsernamePasswordVerifier, AnythingGoesUsernamePasswordVerifier>() );
container.Install( Castle.Windsor.Installer.Configuration.FromXmlFile( "Windsor.xml" ) );

Like it? Not? Have a better solution? Please let me know!

Written by anderssonjohan

October 28, 2009 at 19:34

Posted in programming

Tagged with , , , ,

Castle Windsor 2.0 RTMed

leave a comment »

Oh yeah! Castle Windsor 2.0 is RTMed!

I just can’t wait ’til we upgrade RemoteX Applications.

Written by anderssonjohan

May 5, 2009 at 12:05

Posted in programming

Tagged with , ,