Почему ASP.NET по-разному разрешает ссылки на сборки?

Я очень старался найти аналогичную проблему, чтобы получить несколько потенциальных клиентов, но, похоже, никто не описывает наш случай, так что вот оно.

Предпосылки

У нас есть продукт со следующим общим дизайном:

[Локальная папка установки]

• Содержит набор сборок .NET, реализующих большую часть функций нашего продукта.
• Пример: Implementation1.dll , Implementation2.dll

[GAC]

• ClientAPI.dll. Наша клиентская сборка, на которую можно ссылаться из проектов Visual Studio конечного пользователя. Имеет сильные ссылки на библиотеки реализации в локальной папке установки.

В ClientAPI.dll у нас есть точка входа, которую мы требуем для запуска проектов конечных пользователей. Назовем его Initialize () .

Самое первое, что мы делаем в Initialize , - это устанавливаем так называемый обработчик разрешения сборки в текущем домене, с помощью события AssemblyResolve . Этот обработчик будет знать, как найти библиотеки реализации и загрузить их в клиентский процесс, используя Assembly.Load () .

Рассмотрим консольное приложение. Это будет выглядеть примерно так:

class Class1
{
    void Main(string[] args)
    {
        ClientAPI.Initialize();

        // Use other API's in the assembly, possibly internally referencing the
        // implementation classes, that now will be resolved by our assembly
        // resolve handler.
    }
 }

Теперь все хорошо в мире console / windows forms / WPF. Наш обработчик разрешения сборки правильно установлен и вызван, и он может успешно разрешать ссылки на DLL реализации, как только ClientAPI.dll требует их функциональности.

Описание проблемы

При этом мы не намерены поддерживать только консоль или WPF приложений, поэтому мы полагались на тот же дизайн в ASP.NET. Следовательно, создавая новый проект веб-приложения ASP.NET в VS 2010, мы полагали, что все будет так же просто, как:

class Globals : HttpApplication
{
    void Application_Start(object sender, EventArgs e)
    {
        ClientAPI.Initialize();

        // ...
    }
}

Несколько 20-30 часов пребывания во вселенной времени выполнения ASP.NET, пробуя описанное выше при разработке сервер и IIS, мы узнали, что там все не так, как мы ожидали.

Оказывается, что в ASP.NET, как только класс ClientAPI упоминается где-нибудь, все ссылки, которые он имеет на любые другие сборки, мгновенно разрешаются . И не только это: результаты кэшируются (по замыслу, начиная с .NET 2.0, который мы обнаружили), что означает, что у нас вообще нет шанса попытаться помочь CLR.

Без дальнейших пояснений по поводу различные вещи, которые мы пробовали и изучали, в основном сводится к следующему у нас вопросу:

Почему ASP.NET разрешает такие ссылки? Это несовместимо с тем, как это делают другие типы приложений, и даже более того, это не соответствует документации .NET / среды выполнения CLR, в которой указывается, что ссылки на внешние типы / сборки должны разрешаться при первой необходимости (т.е. впервые используется в коде).

Мы будем очень признательны за любые идеи / идеи!