1

I started working in a DI framework (just for fun) a few weeks ago, and while building it I came across the following issue. Basically most of us are concern about using DI frameworks so that we code against interfaces rather than implementations, and I completely agree with this SOLID principle - I'm a big fan/user of DI frameworks myself - but we then make our code dependent on third party libraries because for example .NET does not provide out of the box DI functionality. Sure they have MEF and Unity but those are external libraries.

So as it stands if I want to use DI I've got to use a third party library and make sure my project references it and apart from that I expose my application to run-time problems that might occur in the library, e.g.: unhandled exceptions.

I can't solve the fact that the component that uses the DI library needs to reference it( at least not yet), but I need a solution to the exceptions: unhandled exceptions occurring within the DI library need to stay within the library, that is, not propagating to the client application, yes a well design library should handle all exceptions but software isn't perfect.

The easiest way to achieve this, that I could think off, is to use ApplicationDomains and use .Net Remoting with named pipes for the interprocess communication. What I need to know from you guys is if there is any other way to create this kind of isolation using other tools/processes.

Thanks

UPDATE

After looking a bit more, I found that this can be easily implemented without having to use .Net Remoting directly:

public interface IRuntime
{
    bool Run();
}

public class Runtime : MarshalByRefObject, IRuntime
{
    public bool Run()
    {
        throw new NotImplementedException();
    }
}

class Program
{
    static void Main(string[] args)
    {
        var domainSetup = new AppDomainSetup()
        {
            ApplicationBase = AppDomain.CurrentDomain.SetupInformation.ApplicationBase,
            ConfigurationFile = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile,
            ApplicationName = AppDomain.CurrentDomain.SetupInformation.ApplicationName,
            LoaderOptimization = LoaderOptimization.MultiDomainHost
        };

        var domain = AppDomain.CreateDomain("Your Child AppDomain", null, domainSetup);

        domain.FirstChanceException += (sender, e) =>
        { };

        Task.Factory.StartNew(() => domain.DoCallBack(() => new Runtime().Run()));

        Console.ReadKey();
    }
}

The sample code above seems to meet my needs.

Thanks

MeTitus
  • 3,390
  • 2
  • 25
  • 49
  • 3
    So, you want to use DI, but you want insulate your application from the IoC, by adding a complicated hand-rolled layer that drags in AppDomains and Remoting? You are going to introduce more problems than you are trying to solve. We've been using AutoFac in production for an MVC app and other goodies for 2 years -- no problems from unhandled exceptions. Don't code to solve a problem you don't yet have. Find an IoC that works for your app and enjoy. – dbugger Jun 29 '13 at 01:15
  • @dbugger I've also used AutoFac extensively with NServiceBus and before I've relied on Unity. I know there are nice IoC tools out there, and what I'm working on is not intended to replace any IoC library I'm using on production environments it is something I'm working on, on my own. Once I finish this library I don't want any client to have to use remoting and ApplicationDomain, that will be implemented in the library. The client would use simple factory services in the IoC and within the library all the other code (core) would be run in an ApplicationDomain, effectively run it in isolation. – MeTitus Jun 29 '13 at 08:54

0 Answers0