.NET不使用AppDomain中加载的Oracle.DataAccess.dll

Question

I keep running into an issue where my ASP.NET web app keeps throwing on error on trying to load Oracle.DataAccess.dll. I'm noticing this issue when I have both the 64-bit and 32-bit Oracle.DataAccess.dll installed.

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.

The 2.102.2.20 is the version I built my projects with.

Specific Version is set to false

The Runtime Version is set to v2.0.5.0727 (in case that matters)

Currently, I am loading a newer Oracle.DataAccess.dll dynamically System.Reflection.Assembly.Load() into the AppDomain. I have my IIS to load 32-bit Applications so it is correctly loading the x86 assembly. I've confirmed that this is loaded and present before my data access layer references Oracle.DataAccess.dll.

In addition, I reviewed my web.config and I do have assembly bindings to target the newer version. Tried with and without the bindings and it doesn't seem to matter.

<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>

Why does .NET try to load the older version? I thought if I have the assembly loaded in the AppDomain, it would just use this version?

---

My GAC for Oracle.DataAccess.dll looks like this:

Oddly enough, my GAC_64 folder's entry for Oracle.DataAccess.dll is empty.

I ran a console utility test that looks for registered .dll is GAC.

---

I did play with my web.config assembly bindings a little and now it works for some reason. Still don't understand what was going on. I added a range and assembly Identity info, perhaps this whole time, it just didn't know what assembly I was talking about in the 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

Well, I don't know if I got the answer I wanted but it appears that the assembly bindings being generated into the web.config may be incomplete or wrong based on some changes I made awhile back.

It appears with the assembly identity information, .NET is able to reconcile that the referenced older assembly can be "replaced" with the newer assembly loaded into the AppDomain. Otherwise, it just has a version number and will ignore the assembly binding in the web.config. What this does confirm to me is that even though I do all this effort to load the newest Oracle.DataAccess.dll, it is really the assembly bindings that decide what version will be used and I shouldn't try to rid my config files of these assembly bindings.

More or less, for my case where I want to control .dll versioning, use assembly bindings generated off looking at what is installed on the machine as needed and do not rely on .NET blindly using the .dll loaded into the app domain.