.NET не использует Oracle.DataAccess.dll, загруженный в AppDomain

Question

У меня проблема с тем, что мое веб-приложение ASP.NET продолжает бросать ошибку при попытке загрузить Oracle.DataAccess.dll. Я замечаю эту проблему, когда у меня установлена ​​и 64-разрядная, и 32-разрядная Oracle.DataAccess.dll.

LOG: DisplayName = Oracle.DataAccess, Version=2.102.2.20, Culture=neutral, PublicKeyToken=89b483f429c47342 (Fully-specified) 
LOG: Appbase = file:///C:/Dev/repository/trunk/myapp/ 
LOG: Initial PrivatePath = C:\Dev\repository\trunk\myapp\bin 

Calling assembly : DataAccess.Oracle, Version=15.0.0.26242, Culture=neutral, PublicKeyToken=null. 

LOG: This bind starts in default load context. 
LOG: Using application configuration file: C:\Dev\repository\trunk\myapp\web.config 
LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet.config 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config. 
LOG: Post-policy reference: Oracle.DataAccess, Version=2.102.2.20, Culture=neutral, PublicKeyToken=89b483f429c47342 
LOG: The same bind was seen before, and was failed with hr = 0x80070002. 

2.102.2.20 версия, с которой я построил свои проекты.

Конкретная версия устанавливается в ложном

исполняющая среда Version установлена ​​в v2.0.5.0727 (в случае, если имеет значение)

В настоящее время я загружая новую Oracle.DataAccess. dll динамически System.Reflection.Assembly.Load() в AppDomain. У меня есть IIS для загрузки 32-разрядных приложений, поэтому он правильно загружает сборку x86. Я подтвердил, что он загружен и присутствует до того, как мой уровень доступа к данным обращается к Oracle.DataAccess.dll.

Кроме того, я просмотрел свой web.config, и у меня есть привязки для привязки к более новой версии. Пробовал с привязками и без них, и это, похоже, не имеет значения.

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
    <dependentAssembly> 
    <bindingRedirect oldVersion="2.102.2.20" newVersion="2.112.1.0" /> 
    </dependentAssembly> 
</assemblyBinding> 
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
    <dependentAssembly> 
    <bindingRedirect oldVersion="2.102.2.20" newVersion="4.112.3.0" /> 
    <publisherPolicy apply="no" /> 
    </dependentAssembly> 
</assemblyBinding> 

Почему .NET пытается загрузить более старую версию? Я думал, что если у меня есть сборка, загруженная в AppDomain, она просто будет использовать эту версию?

---

Мой GAC для Oracle.DataAccess.dll выглядит следующим образом:

Как ни странно, запись моей GAC_64 папки для Oracle.DataAccess.dll пуст.

Я запустил консольный утилитный тест, который ищет зарегистрированный .dll - это GAC.

---

Я играю с web.config монтажными креплениями немного и теперь он работает по какой-то причине. Все еще не понимаю, что происходит. Я добавил диапазон и информацию об идентификационной информации, возможно, все это время, она просто не знала, какую сборку я рассказывал в web.config.

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
    <dependentAssembly> 
    <assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89B483F429C47342"/> 
    <bindingRedirect oldVersion="2.102.2.20-2.102.9999.9999" newVersion="2.112.1.0" /> 
    </dependentAssembly> 
</assemblyBinding> 
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
    <dependentAssembly> 
    <assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89B483F429C47342"/> 
    <bindingRedirect oldVersion="2.102.2.20-2.102.9999.9999" newVersion="4.112.3.0" /> 
    <publisherPolicy apply="no" /> 
    </dependentAssembly> 
</assemblyBinding> 

Answer 1

Ну, я не знаю, если я получил ответ, что я хотел, но кажется, что сборка привязки генерируются в web.config может быть неполными или неправильно основанные на некоторых изменениях, которые я сделал некоторое время назад.

Он появляется с идентификационной информацией о сборке, .NET может согласовать, что упомянутая старая сборка может быть заменена новой сборкой, загруженной в AppDomain. В противном случае он просто имеет номер версии и будет игнорировать привязку сборки в файле web.config. Что это мне подтверждает, так это то, что, несмотря на то, что я прилагаю все усилия для загрузки новейшего файла Oracle.DataAccess.dll, это действительно привязки к сборке, которые определяют, какая версия будет использоваться, и я не должен пытаться избавиться от моих конфигурационных файлов эти монтажные привязки.

Более или менее, для моего случая, когда я хочу управлять версиями .dll, используйте привязки для сборки, сгенерированные с учетом того, что установлено на компьютере, при необходимости, и не полагайтесь на .NET вслепую, используя .dll, загруженную в домен приложения.