It is not a secret that I love Spring.Net, it just makes the development of big application a pleasure. During the port of Ubuntu One to Windows I have been using the framework to initialise the WCF service that we use to provide other .Net applications the ability of communicating with Ubuntu One. Yes, this is our DBus alternative!
The idea behind using WCF is to allow other applications to use the different features that Ubuntu One provides, the very first application that we would like to use this would be Banshee on Windows (I have to start looking into that, but I have too much to do right now). In order to provide this functionality we use named pipes to allow the communication, there are two reasons for this:
- For an application to host a WCF service that uses a binding besides the named pipe binding requires special permissions. This is clearly a no no for a user application like Ubuntu One.
- Named pipes are dammed efficient!!! Named pipes on Windows are at the kernel level, cool
Initially I though of hosting the WCF services as a Windows services, why not?!?! Once I had this feature implemented, I realized the following. It turns out that while impersonation does get spawn within different threads, this is not the case for processes. This is a major pain in the ass. The main reason for this being a problem is the fact that if an application is executed in a different user space, the different env variables that are used are those of the user executing the code. This means that things like your user roming app dir will not be able to use, plus other security issues.
After realizing that the WCF services could not be hosted on a Windows service, I moved to write a work a round that would do the following:
- Configure the WCF services to use named pipes only for the current user.
- Start a console application that will host the WCF services.
- Start the different WCF clients for Ubuntu One (currently is our clietn app, but should it could be your own!
Although the definition of the solution is simple, we have to work around the issue that up ’til now all our WCF services were defined through configuration and were injected by the spring.net IoC. Usually you can change the location of you app domain configuration by using the following code:
AppDomain.CurrentDomain.SetData(“APP_CONFIG_FILE”,”c:\\ohad.config”);
In theory wth the above code you can redirect the configuration to a new file, and if you use for example:
System.Configuration.ConfigurationSettings.AppSettings["my_setting"]
you will be able to get the value of your new configuration. Unfortunatly, the Spring.Net IoC uses the ConfigurationManager class which ignores that setting… Now what?
Well, re-writting all the code to not use Spring.Net IoC was not an option because it means changing a lot of work and does mean to move from an application where dependencies are injected to one were we have to manually init all the different objects. After some careful though, I move to use a small CLR detail that I knew to make the AppDomain that executed our code to use the users configuration. The trick is the following, use one AppDomain to start the application. This would be a dummy AppDomain that does not execute any code at all but launches a second AppDomain whose configuration is the correct one and which will execute the actual code.
In case I did not make any sense, here is an example code:
using System; using Canonical.UbuntuOne.Common.Container; using Canonical.UbuntuOne.Common.Utils; using log4net; namespace Canonical.UbuntuOne.ProcessDispatcher { static class Program { private static readonly ILog _logger = LogManager.GetLogger(typeof(Program)); private static readonly ConfigurationLocator _configLocator = new ConfigurationLocator(); /// <summary> /// This method starts the service. /// </summary> static void Main() { _logger.Debug("Redirecting configuration"); // Setup information for the new appdomain. var setup = new AppDomainSetup { ConfigurationFile = _configLocator.GetCurrentUserDaemonConfiguration() }; // Create the new appdomain with the new config. var executionAppDomain = AppDomain.CreateDomain("ServicesAppDomain", AppDomain.CurrentDomain.Evidence, setup); // Call the write config method in that appdomain. executionAppDomain.DoCallBack(() => { _logger.Debug("Starting services."); // use the IoC to get the implementation of the SyncDaemon service, the IoC will take care of // setting the object correctly. ObjectsContainer.Initialize(new SpringContainer()); var syncDaemonWindowsService = ObjectsContainer.GetImplementationOf<SyncDaemonWindowsService>(); // To run more than one service you have to add them here syncDaemonWindowsService.Start(); while (true) ; }); } } }
Well I hope this helps someone else 
Latest Official Posts
