Question

I have a very large project that uses Oracle ODP.NET. Right now it is building against version 10.1.0.401 (which is a pretty old version at this point). This is working on my dev machine as well as the build machine. The build machine does not have Visual Studio installed but rather uses MSBuild directly against the solution file.

I’m trying to install a new version of ODP on my developer machine. However, I don’t want to impact other developers, or the build machine. I want to allow people to upgrade versions at different times, and I can’t upgrade the build machine until our web servers are upgraded (corporate environment – this will take months).

Right now, in source control, the Oracle.DataAccess reference in the *.csproj file looks like this:

<Reference Include="Oracle.DataAccess, Version=10.1.0.401, Culture=neutral, PublicKeyToken=89b483f429c47342" />

So SpecificVersion is set to true, and 10.1.0.401 is in the GAC on the build machine. This builds fine. So I figure that I’ll just change the reference to SpecificVersion false, and commit it. On my machine, the reference will resolve to the new version, and on the build machine it will continue to resolve to 10.1.0.401. So I commit a change to the file that looks like this:

<Reference Include="Oracle.DataAccess, Version=10.1.0.401, Culture=neutral, PublicKeyToken=89b483f429c47342">
  <SpecificVersion>False</SpecificVersion>
</Reference>

Somehow, this causes the MSBuild execution on the build server to have a compilation failure. The error is:

"C:\path\to\MySolution.sln" (Rebuild target) (1) ->
"C:\path\to\my\project.csproj" (Rebuild target) (2) -> 
  (CoreCompile target) ->
  My\ClassFile.cs(241,67): error CS1061: 'Oracle.DataAccess.Client.OracleConnection' does not contain a definition for 'EnlistDistributedTransaction' and no extension method 'EnlistDistributedTransaction' accepting a first argument of type 'Oracle.DataAccess.Client.OracleConnection' could be found (are you missing a using directive or an assembly reference?) [C:\path\to\my\project.csproj]

It would make sense to me if it couldn’t find Oracle.DataAccess at all, but how am I getting a compilation error about a missing API? Note that that API is present in ODP 10.1.0.401 so it is not a legitimate error from what I can tell.

Update:
This is somehow related to the DLL being in the GAC. If I have the DLL locally and change the reference so it includes a HintPath to that local file, then the thing compiles fine. Is it not appropriate to combine SpecificVersion = False with GACed assemblies?

Answer 1

I’m also using this assembly. We are referencing this assembly from the “Assemblies” folder inside project directory tree with specific version = false.

<Reference Include="Oracle.DataAccess, Version=2.111.6.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=x86">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\..\Assemblies\Llblgen\Oracle.DataAccess.dll</HintPath>
</Reference>

It is working because all team members has the same version installed on their machines. On the build server there was the different situation. I don’t remember why but I had to add assembly binding redirect into the machine.config for Oracle assemby to get my builds working on 64bit build server.

It was probably caused by new ODP.NET where two Oracle.DataAccess assemblies were installed into the GAC. One for the .NET 4.0 with version 4.xx and 2nd with version 2.111.xx. I compiled my sources using MSBuild 4.0 (TFS2010) (our projects are targetting .NET3.5) and it always tried to load 4.xx version instead of 2.xx version from the GAC.

I solved it by updating of one of the machine.config files:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89B483F429C47342" culture="neutral" />
        <bindingRedirect oldVersion="2.102.0.0-2.120.0.0" newVersion="2.112.2.0" />
      </dependentAssembly>
    </assemblyBinding>
</runtime>

Sorry, I don’t remember exactly my Oracle issue on the build server, but this assembly redirect was helpful.