CODEWITHSUNDEEP
c#asp.netoracleclient
jimo3
jimo3

Reputation: 418

How to force an ASP.NET Web app to use Oracle DLLs in the BIN folder?

So I have an web app that need the Oracle 19c client (4.122.19.1) due to certain syntax changes, while our Dev IIS server has an older 4.121.2.0 client.

Anyway, I put all of what I've heard to be the proper support dlls in the Bin directory of the app, which from all my research are these: oci.dll ociw32.dll Oracle.ManagedDataAccess.dll Oracle.Web.dll orannzsbb19.dll oraocci19.dll oraocci19d.dll oraociei19.dll oraons.dll OraOps19.dll

This runs perfectly from my PC in Visual Studio. When I deploy to a Dev IIS server (with app-pool running in Enable 32-bit because my PC runs IISExpress in 32-bit) There are various Oracle connection errors.

Now, in Process Explorer, on my PC, I look at the IISExpress and I can see it's loaded all of the above dlls, though from the GAC because I have this client installed locally. Yet on the Dev server, Process Explorer, under my W3WP.exe process, I see only the Oracle.ManagedDataAccess.dll and Oracle.Web.dll, but none of the support DLLS. I'm fairly certain the fact that these are missing, especially OraOps19.dll, is the issue.

I've used the "DLLPath" thing in the web.config, it makes no difference. I was always told that Asp.Net always trys to load from the BIN first. Yet here I believe it is at least partially ignoring it--both in my PC, which is going straight to the GAC, and from the Dev IIS server, which does get the proper .Web and .ManagedDataAccess from Bin, but nothing else.

How can I make this forget the Gac and force it to find anything it needs Oracle-wise in the Bin? Thanks

Upvotes: 1

Views: 657

Answers (1)

Joshua
Joshua

Reputation: 43317

The dlls are bugged; it's not allowed to release breaking changes to signed dlls like that. Workaround:

Assuming these are 100% il code (no C++/clr involved)

  1. ildasm the oracle dlls to .il and .res files
  2. Remove all references to the public key
  3. ilasm the .il and .res files back to dlls
  4. link your application against those dlls

Now it doesn't look in the GAC anymore.

Upvotes: 1

Related Questions