Я считаю, что ASP.NET довольно часто копирует ваши сборки, чтобы избежать блокировки оригинальной DLL (что предотвратит перезапись новой версией). Затем, когда вы перезаписываете его, ему требуется копия старой версии, пока не будут выполнены все невыполненные запросы, а также новая версия, используемая для новых запросов.
Таким образом, ваша DLL не запускается из каталога \bin\, в который вы ее поместили, и ищет собственные зависимости, где она действительно выполняется.
Вы можете указать собственные пути к DLL или добавить код для явного копирования их в «настоящий» каталог сборки по мере необходимости. Но у вашего кода даже не должно быть разрешения на запись в файловую систему, поэтому я думаю, что вы застряли, используя путь.
Обратите внимание, что вы можете добавлять каталоги в собственную среду приложения, не влияя на глобальный путь. Например, p / invoke SetDllDirectory Не добавляйте \bin\. Поместите свои собственные библиотеки DLL в отдельный каталог, например \bin\native или \bin\x86, чтобы при изменении пути поиска не изменялось, какие управляемые библиотеки DLL были найдены.
Edit:
Это работает только в том случае, если задержка управляемой DLL загружает любые неуправляемые собственные библиотеки DLL, на которые она ссылается (используя / DELAYLOAD). В противном случае компиляция global.asax (или там, где происходит установка пути) не удастся.