Ich habe bereits eine andere Frage gestellt, aber nach einigen Beobachtungen habe ich mich auf das beschränkt, was möglicherweise mein Problem verursacht. Sobald der IIS-Anwendungspool wiederverwendet wurde, schlägt meine Abhängigkeitsinjektion (die letztendlich durch Erstellen einer NWatchApplication nach einigen DLLs sucht) im Grunde fehl. INWatchApplication ist eine Abhängigkeit für das Web-API-Projekt.

Hier ist der Inhalt von Global.asax:

protected void Application_Start()
{
    AreaRegistration.RegisterAllAreas();
    GlobalConfiguration.Configure(WebApiConfig.Register);
    FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
    RouteConfig.RegisterRoutes(RouteTable.Routes);
    BundleConfig.RegisterBundles(BundleTable.Bundles);

    var webApiContainer = new Container();
    webApiContainer.Options.DefaultScopedLifestyle = new WebApiRequestLifestyle();
    RegisterTypes(webApiContainer);
    webApiContainer.RegisterWebApiControllers(GlobalConfiguration.Configuration);
    webApiContainer.Verify();

    GlobalConfiguration.Configuration.DependencyResolver =
        new SimpleInjectorWebApiDependencyResolver(webApiContainer);
}

private void RegisterTypes(Container container)
{
    var virtualPath = HostingEnvironment.ApplicationVirtualPath.Substring(1);
    string baseName = null;

    if (!string.IsNullOrEmpty(virtualPath)) {
        baseName = HostingEnvironment.SiteName + "_" + virtualPath;
    } else {
        baseName = HostingEnvironment.SiteName;
    }

    var nWatchApp = new NWatchEntityApplication(GetNWatchConfig());
    Trace.Listeners.Add(new DevOps.Diagnostics.DevOpsLogTraceListener(baseName));
    container.RegisterSingleton<INWatchApplication>(nWatchApp);
    container.Register<NWatchDbContext>(() => nWatchApp.GetDbContext(), Lifestyle.Scoped);
}

private INWatchConfiguration GetNWatchConfig()
{
    Configuration rootConfig =
        System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(HostingEnvironment.ApplicationVirtualPath);
    return new NWatchSystemConfiguration(rootConfig);
}

Ich habe verschiedene Blogs und Posts gelesen, in denen es darum ging, wie dynamisch geladene DLLs problematisch zu sein scheinen, da sie beim Recycling der Pools von IIS nicht in die AppDomain kopiert werden. (Ich könnte hier völlig falsch liegen, aber es ist mein Verdacht).

Wie kann ich sicherstellen, dass alle DLLs, die möglicherweise geladen wurden (als die Anwendung zum ersten Mal in IIS bereitgestellt wurde), auch nach einem Recycling für die Anwendung verfügbar sind?