ASP.NET - AppDomain.CurrentDomain.GetAssemblies() - Assemblies missing after AppDomain restart

I have a Bootstrapper that looks through all Assemblies in an ASP.NET MVC application to find types that implement an IBootstrapperTask interface, and then registers them with an IOC Contrainer. The idea is that you can literaly place your IBootstrapperTasks anywhere, and organise your Projects how you please.

Code for Bootstrapper:

public class Bootstrapper
{
    static Bootstrapper()
    {
        Type bootStrapperType = typeof(IBootstrapperTask);

        IList<Assembly> assemblies = AppDomain.CurrentDomain.GetAssemblies();

        List<Type> tasks = new List<Type>();

        foreach (Assembly assembly in assemblies)
        {
            var types = from t in assembly.GetTypes()
                        where bootStrapperType.IsAssignableFrom(t)
                            && !t.IsInterface && !t.IsAbstract
                        select t;

            tasks.AddRange(types);
        }

        foreach (Type task in tasks)
        {
         开发者_StackOverflow社区   if (!IocHelper.Container().Kernel.HasComponent(task.FullName))
            {
                IocHelper.Container().AddComponentLifeStyle(
                    task.FullName, task, LifestyleType.Transient);
            }
        }
    }

    public static void Run()
    {
        // Get all registered IBootstrapperTasks, call Execute() method
    }
}

After a full build, AppDomain.CurrentDomain.GetAssemblies() returns all Assemblies in my solution (including all the GAC one's but that doesn't bother me).

However, if the AppDomain is restarted, or I 'bounce' the Web.Config file (adding a space and saving), the static constructor is run again but when AppDomain.CurrentDomain.GetAssemblies() is called, most of the Assemblies are missing, including the one containing my IBootstrapperTask types.

How do I get around this problem? I guess I could System.IO the /bin directory and load all the DLLs in there manually, but would rather avoid this if possible, or is that the only way? Am I taking the right general approach to this?

This is an ASP.NET MVC 2.0 application running on .NET 4.0, I get this problem with the built-in Visual Studio 2010 Cassini web server, and with IIS7.0 in Integrated Pipeline Mode on Windows Server 2008.

---

Edit: I just came across this SO post Difference between AppDomain.GetAssemblies and BuildManager.GetReferencedAssemblies which says the AppDomain only loads the Assemblies as they're needed (eg. when a method/class from that Assembly is first called). I guess that would explain why the Assemblies are missing on AppDomain.CurrentDomain.GetAssemblies() as the Bootstrapper is run very early on.

I noticed if I placed a call to 'something' from the missing Assembly before the Bootstrapper eg:

public class MvcApplication : System.Web.HttpApplication
{
    protected void Application_Start()
    {
        MyApp.MissingAssembly.SomeClass someClass =
            new MyApp.MissingAssembly.SomeClass();

        Bootstrapper.Run();
    }
}

...it seems to fix the problem, but it is a bit of a hack.

---

I looked through the ASP.NET MVC 2.0 source code and looked up how AreaRegistration.RegisterAllAreas(); is implemented. This line is usually put into the Global.asax Application_Start() method and internally it scans all Assemblies for types that implement the AreaRegistration abstract type. This is kinda the behaviour I'm after.

It appears RegisterAllAreas() makes a call to BuildManager.GetReferencedAssemblies(), well if it's good enough for MVC then it's good enough for me :-)

I've done some experimentation and BuildManager.GetReferencedAssemblies() will even pick up adhoc, random DLL's dropped into the /bin folder, even with no references to any projects in the Visual Studio solution. So it appears far more reliable than AppDomain.Current.GetAssemblies().

I've rewritten my Assembly locator code to the following:

using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.IO;
using System.Linq;
using System.Reflection;
using System.Web;
using System.Web.Compilation;

public static class AssemblyLocator
{
    private static readonly ReadOnlyCollection<Assembly> AllAssemblies;
    private static readonly ReadOnlyCollection<Assembly> BinAssemblies;

    static AssemblyLocator()
    {
        AllAssemblies = new ReadOnlyCollection<Assembly>(
            BuildManager.GetReferencedAssemblies().Cast<Assembly>().ToList());

        IList<Assembly> binAssemblies = new List<Assembly>();

        string binFolder = HttpRuntime.AppDomainAppPath + "bin\\";
        IList<string> dllFiles = Directory.GetFiles(binFolder, "*.dll",
            SearchOption.TopDirectoryOnly).ToList();

        foreach (string dllFile in dllFiles)
        {
            AssemblyName assemblyName = AssemblyName.GetAssemblyName(dllFile);

            Assembly locatedAssembly = AllAssemblies.FirstOrDefault(a =>
                AssemblyName.ReferenceMatchesDefinition(
                    a.GetName(), assemblyName));

            if (locatedAssembly != null)
            {
                binAssemblies.Add(locatedAssembly);
            }
        }

        BinAssemblies = new ReadOnlyCollection<Assembly>(binAssemblies);
    }

    public static ReadOnlyCollection<Assembly> GetAssemblies()
    {
        return AllAssemblies;
    }

    public static ReadOnlyCollection<Assembly> GetBinFolderAssemblies()
    {
        return BinAssemblies;
    }
}

---

Looks like you solved your own problem.

Edit: Personally, I would actually enumerate the assemblies, one by one, load them and look for the interface. Do it based of files rather than what the AppDomain is doing.