0

When I use my CruiseControl.NET Build Server to build my C# application it always references to the wrong Oracle.DataAccess.dll. On my local machine it is working without any problems.

My local machine and my build server are both Windows 7 machines. I installed the Oracle Client 11.2.0.3 (32 AND 64 bit) on both machines. My application is a .NET Framework 4.0 C# application. I set specific version and local copy of the OracleDataAccess.dll to false.

When I build it on my local machine everything works fine. I analyzed the file using IL-Disassembler, the reference here is ok:

.assembly extern Oracle.DataAccess
{
  .publickeytoken = (89 B4 83 F4 29 C4 73 42 )                         // ....).sB
  .ver 4:112:3:0
}

When I build it on the build server my application references to the wrong OracleDataAccess.dll. Here I get this reference:

.assembly extern Oracle.DataAccess
{
  .publickeytoken = (89 B4 83 F4 29 C4 73 42 )                         // ....).sB
  .ver 2:112:3:0
}

All the references in the project point to the 4... version. I reinstalled the 32 and 64 bit oracle clients. I checked all the oracle references on the build server, everything looks fine. After trying to find the error the whole day I don't know how to continue. Please, can someone help me with this problem?

Pinzi
  • 293
  • 6
  • 18
  • 1
    As a debugging step I recommend using [ProcessMonitor](https://technet.microsoft.com/en-us/library/bb896645.aspx) with a filter for any path which contains `Oracle.DataAccess.dll` while running your build. This will help you identify all the locations this DLL is being loaded from. – kdtong Apr 07 '15 at 14:11
  • The MSBuild process loads both, the 2.. and 4.. version. 2.112.3.0 is loaded from C:\Windows\assembly and 4.112.3.0 is loaded from C:\Windows\Microsoft.NET\assembly\GAC_32 – Pinzi Apr 08 '15 at 08:27

1 Answers1

0

In your *.csproj edit your reference to ODP.NET like this:

    <Reference Include="Oracle.DataAccess">
      <SpecificVersion>False</SpecificVersion>
      <Private>False</Private>
    </Reference>

Attributes like Version=... or processorArchitecture=... are not required. Your application will load the correct Oracle.DataAccess.dll depending on selected architecture and target .NET framework (provided that it is installed properly)

Wernfried Domscheit
  • 54,457
  • 9
  • 76
  • 110
  • I removed these fields, but it doesn't change anything. It still has the reference to the 2.112.3.0 version in it. I'll try to install a Visual Studio on the server, maybe this helps me to find out how the dlls are loaded. – Pinzi Apr 08 '15 at 08:30
  • Installing Visual Studio on the server is most probably an overkill (and perhaps it will not work either). Have a look at this: http://stackoverflow.com/questions/659341/the-provider-is-not-compatible-with-the-version-of-oracle-client#25412992 – Wernfried Domscheit Apr 08 '15 at 09:29
  • We created a copy of our build-server and I tried to do the things described in your post, but it still takes the wrong Oracle.DataAccess.dll. I now installed a Visual Studio on our new build server copy. There I see the version of the Oracle.DataAccess is 2.112.3.0 and not 4.112.3.0. I opend exactly the same project I opened at my local machine before, on my machine it references to 4... on the build server it references to 2... Very strange... – Pinzi Apr 13 '15 at 10:08
  • Please provide all following settings: Architecture (x64 or x86) of your application, Target Version of .NET Framework, Architecture and version of installed Oracle Client, content of GAC, e.g. run `gacutil /l Oracle.DataAccess` from Visual Studio Developer command prompt. – Wernfried Domscheit Apr 13 '15 at 14:25
  • Architecture: x86 (but same problem with x64), .NET Framework 4.0 --- Oracle Client 11.2.0.3 x86 and x64 are installed --- gacutil /l Oracle.DataAccess returns: Microsoft (R) .NET Global Assembly Cache Utility. Version 4.0.30319.17929 Copyright (c) Microsoft Corporation. Alle Rechte vorbehalten. Der globale Assemblycache enthält die folgenden Assemblys: Oracle.DataAccess, Version=2.112.3.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=x86 Oracle.DataAccess, Version=4.112.3.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=x86 – Pinzi Apr 14 '15 at 08:47
  • Did you follow this instruction when you installed x86 and x64 Oracle Client: http://stackoverflow.com/questions/24104210/badimageformatexception-this-will-occur-when-running-in-64-bit-mode-with-the-32#24120100 – Wernfried Domscheit Apr 14 '15 at 09:01
  • I'll try it again. I delete the clients and follow your instructions. We had a similar problem on another machine, there is was enough the remove the Oracle.DataAccess reference and add the correct one. One thing I just noticed, on our Build Server this isn't possible, because I can only choose the 2.. version of the Oracle.DataAccess when I add a reference – Pinzi Apr 14 '15 at 09:33
  • And I'm sorry I coped the wrong output of the gacutil before, this is the correct one: Oracle.DataAccess, Version=2.112.3.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=AMD64 Oracle.DataAccess, Version=2.112.3.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=x86 Oracle.DataAccess, Version=4.112.3.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=AMD64 Oracle.DataAccess, Version=4.112.3.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=x86 – Pinzi Apr 14 '15 at 09:37
  • Then you must compile to target .NET Framework version lower than 4.0, e.g. to 3.5. Otherwise you application will try to load 4.x – Wernfried Domscheit Apr 14 '15 at 12:14
  • I should load 4.x, but it always loads 2.x – Pinzi Apr 14 '15 at 12:57
  • Almost unbelievable when you set target .NET Framework to version 4.0 – Wernfried Domscheit Apr 14 '15 at 14:35
  • I know, but it loads the Oracle 2.x version when the .NET target is 4.0. – Pinzi Apr 20 '15 at 12:42
  • Yes, of course. The build works fine, just the Oracle.DataAccess is the wrong one. I saw there in the machine.config of the .NET Framework I have an entry on my local machine, but there is now entry on the server. Could this be the problem? – Pinzi Apr 22 '15 at 07:05
  • http://www.oracle.com/technetwork/topics/dotnet/downloads/index.html -> I installed the 3rd link from here and the reference of a 64-bit Application is ok now. But when i try to start it on my local PC I get a "The provider is not compatible with the version of Oracle client" exception :( :( :( – Pinzi Apr 22 '15 at 09:03
  • Check these answers: http://stackoverflow.com/questions/659341/the-provider-is-not-compatible-with-the-version-of-oracle-client#25412992 – Wernfried Domscheit Apr 22 '15 at 13:09
  • I already tried this, without success. I think the problem is somewhere else, because the msbuild finds the Oracle.DataAccess.dll, but not the 4.x ones, i finds the 2.x ones. I have installed the "normal" Oracle Client 11.2.0.3 32 and 64 bit, does the msbuild require anything else like specific ODP.NET installations? (For example on my local machine the "Oracle Developer Tools for Visual Studio" are installed, on my build server there is no Visual Studio so I cannot install this, but is there anything else I have to install?) – Pinzi Apr 22 '15 at 13:20
  • Installing of these clients (http://www.oracle.com/technetwork/topics/dotnet/downloads/index.html) solved the problem. – Pinzi Apr 30 '15 at 08:14