GAC 2.0

A colleague stopped by today with a simple question that derailed my whole afternoon. We're just getting started with deploying .Net Framework 2.0 to servers, and he was wondering: "Do we need a new version of the Oracle Data Provider for Oracle?".

I hadn't thought about that yet. My first questions were "What happened to the old one, and what's going on with the GAC in 2.0?"

The GAC was easy enough to figure out. The %windir%\assembly shell view now shows both 1.x assemblies and 2.x assemblies. Behind the scenes in the file system, there's a new GAC_MSIL folder and a GAC_32 (or GAC_64 if you're on a 64-bit machine).

This series of posts describes it all in more detail, including the behavior of the loaders:
Wonders of the Whidby GAC

Short version: 2.x assemblies are invisible to Framework 1.x, but the other permutations should work.

With that mystery solved, the next question was "What have they done with ADO.Net?".

I created a simple VS 2005 project with the Microsoft System.Data.OracleClient 1.1 version. Tested that, no problem. Next I tried to add a reference to the System.Data.OracleClient 2.0 version. Wouldn't let me. The namespaces are the same, so no surprise. I deleted the 1.1 reference, added the 2.0 reference, recompiled, tested. It worked just fine with zero changes. So for a simple test case, they seem to be completely backwards compatible. For the fun of it, I pulled the assemblies out of the GAC, ran ILDasm on them, and compared the dumps. All the core classes the same. It looks like a couple things have been dropped, and the 2.0 version has some new connection pooling stuff. Which pretty much matches what Microsoft has to say here:

What's New in ADO.Net

As for the original question regarding the Oracle Data Provider for Oracle, Oracle says that an ADO.Net 2.0 compliant assembly will ship with ODP.Net 10.2 in early 2006:

Oracle ODP.Net FAQ

In the meantime, I don't see anything that would prevent the 1.x provider from working in 2.x applications.

File Under: Technology,