6

I have a .NET 3.5 assembly that references ODP (Oracle.DataAccess.dll), building in Visual Studio 2010. Copy Local = False, Specific Version is false. The path is 

C:\[ORACLE_BASE]\product\11.2.0\client_1\ODP.NET\bin\2.x\Oracle.DataAccess.dll

The version is 2.112.3.0, (Runtime v.2.0.50727). I have ODAC 11.2.0.3.0 x86 installed on my development machine. When I build this project and test it in an integration test, everything works fine and ODP is loaded and used. I'm trying to build the same integration test on Team City 7, on a Windows Server 2003 x64 machine, using MSBuild (via Team City). This machine has the same version of ODAC installed, but the x64 version.

There's a problem trying to load up the Oracle.DataAccess.dll. It seems that it's looking for the .NET 2 version, but first finds the .NET 4 version, and then inevitably fails. Looking at the logs, it finds the .NET 4 version, but still can't resolve the reference and appears to explicitly be looking for the x86 version. The configuration for MSBuild is: MSBUILD Version: .NET 4.0 Run Platform x86.

CSProject reference:

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

(I tried changing the Run Platform to x86, and seems to accept the Oracle.DataAccess.DLL library, but complains that all the other core .NET libraries are targeting the wrong platform, e.g. mscorlib

I'm also trying to do a build via a rake script which uses msbuild to build the project solution, and get similar issues.

Questions: How can I get this to build properly on my x64 machine? The x86 and the x64 versions of the libraries have the same PublicKeyToken, so shouldn't it work? Can a Reference tag in a CSProj be set to target "Any CPU" rather than explicitly x64 (by manually editing the file)? Or, is there some way to set up a way to conditionally reference a library depending on the build machine's architecture, as shown here (not exactly sure what the problem is, but this might be a solution)?

[14:30:09]PrepareForBuild:
[14:30:09]  Creating directory "bin\Debug\".
[14:30:09]ResolveAssemblyReferences:
[14:30:09]  Unified primary reference "Oracle.DataAccess, Version=4.112.3.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=x86".
[14:30:09]      Using this version instead of original version "2.112.3.0" in "D:\TeamCity\buildAgent\work\f2ad3a714cc001ba\Source\MyProj\MyProj.Data.Oracle\bin\Debug\MyProj.Data.Oracle.dll" because AutoUnify is 'true'.
[14:30:09]C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9): warning MSB3245: Could not resolve this reference. Could not locate the assembly "Oracle.DataAccess, Version=4.112.3.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=x86". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [D:\TeamCity\buildAgent\work\f2ad3a714cc001ba\Source\MyProj\MyProj.IntegrationTests\MyProj.IntegrationTests.csproj]
[14:30:09]          For SearchPath "D:\TeamCity\buildAgent\work\f2ad3a714cc001ba\Source\MyProj\MyProj.Data.Oracle\bin\Debug".
[14:30:09]          Considered "D:\TeamCity\buildAgent\work\f2ad3a714cc001ba\Source\MyProj\MyProj.Data.Oracle\bin\Debug\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "D:\TeamCity\buildAgent\work\f2ad3a714cc001ba\Source\MyProj\MyProj.Data.Oracle\bin\Debug\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          For SearchPath "{TargetFrameworkDirectory}".
[14:30:09]          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          For SearchPath "{Registry:Software\Microsoft\.NETFramework,v4.0,AssemblyFoldersEx}".
[14:30:09]          Considered "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\x64\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\x64\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Itanium\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Itanium\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\VSTA\v9.0\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\VSTA\v9.0\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Common Files\Microsoft Shared\MSEnv\PublicAssemblies\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Common Files\Microsoft Shared\MSEnv\PublicAssemblies\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          Considered "D:\ODAC_Base\product\11.2.0\client_1\ODP.NET\bin\2.x\Oracle.DataAccess.dll", but its name "Oracle.DataAccess, Version=2.112.3.0, Culture=neutral, PublicKeyToken=89b483f429c47342" didn't match.
[14:30:09]          Considered "D:\ODAC_Base\product\11.2.0\client_1\ODP.NET\bin\2.x\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Microsoft Chart Controls\Assemblies\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Microsoft Chart Controls\Assemblies\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          Considered "D:\ODAC_Base\product\11.2.0\client_1\ASP.NET\bin\2.x\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "D:\ODAC_Base\product\11.2.0\client_1\ASP.NET\bin\2.x\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          For SearchPath "{AssemblyFolders}".
[14:30:09]          Considered "C:\Program Files (x86)\Microsoft SQL Server\100\SDK\Assemblies\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Microsoft SQL Server\100\SDK\Assemblies\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Microsoft.NET\ADOMD.NET\100\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Microsoft.NET\ADOMD.NET\100\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Microsoft SQL Server\100\SDK\Assemblies\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Microsoft SQL Server\100\SDK\Assemblies\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Tasks\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Tasks\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Microsoft SQL Server\100\DTS\PipelineComponents\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Microsoft SQL Server\100\DTS\PipelineComponents\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          Considered "c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Microsoft SQL Server\100\DTS\ForEachEnumerators\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "C:\Program Files (x86)\Microsoft SQL Server\100\DTS\ForEachEnumerators\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]          For SearchPath "{GAC}".
[14:30:09]          Considered "Oracle.DataAccess, Version=4.112.3.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=x86", which was not found in the GAC.
[14:30:09]          For SearchPath "bin\Debug\".
[14:30:09]          Considered "bin\Debug\Oracle.DataAccess.dll", but it didn't exist.
[14:30:09]          Considered "bin\Debug\Oracle.DataAccess.exe", but it didn't exist.
[14:30:09]GenerateTargetFrameworkMonikerAttribute:
Stealth Rabbi
  • 10,156
  • 22
  • 100
  • 176

1 Answers1

6

I had the same issue. The problem was in the MsBuild version on the server. I used Msbuild 4.0 and it is using v4.0 runtime instead of 2.0.xx used in MsBuild 3.5.

Try to use Msbuild 3.5 if possible. If not, check your GAC if you have ODP installed correctly. I don't remember exactly how I fixed it for MSBuild 4.0, but I had to play with GAC assemblies and machine.config.

This is my GAC listing for Oracle.DataAccess.dll on our 64bit build server: Oracle.DataAccess.dll in my GAC

This is the part of machine.config. I had to add assembly redirect:

<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>
      <dependentAssembly>
    </assemblyBinding>
</runtime>

I updated all machine.configs to be sure :) But updating Framework64 machine.config should be enough.

Ludwo
  • 6,043
  • 4
  • 32
  • 48
  • 1
    On my build machine, I only have Version 2.112.3.0 and 4.112.3.0 of AMD64. x64 isn't listed there. Do you mean app.config not machine.config, or does it need to be done on the machine's config? I set my CSPRoj up to not look for specific version, so shouldn't that cover your machine.config changes? – Stealth Rabbi Feb 29 '12 at 12:49
  • 1
    For the teamcity bulids that use MSBUild (not the rake script), setting it to .NET 3.5 for MSBuild causes other assemblies to fail to build, indicating that it can't find LINQ. This confuses me since LINQ is in .NET 3.5 – Stealth Rabbi Feb 29 '12 at 13:06
  • 1
    It appears that you may have installed ODAC 32bit and 64 bit? Also, in my first comment, I meant to say that "x86 isn't listed there" in my second sentence. Can't edit it now. – Stealth Rabbi Feb 29 '12 at 13:37
  • 1
    Well. I probably installed both 32&64 bit. In therory, 64bit installation should be enough. I updated machine.config inside .NET framework installation folder. There are two, one for the 2.0.x runtime and one for 4.0 runtime. Sorry, it was long time ago and I don't remember exactly what I did one year ago... – Ludwo Feb 29 '12 at 13:54
  • 1
    Well, I ended up installing both x86 and x64 and it's working. I put x86 in a separate ORACLE_HOME base and it built fine, and I didn't have to change any Team City settings (still doing MSBuild v4.0). I didn't end up having to change any machine.config. – Stealth Rabbi Feb 29 '12 at 14:49
  • 1
    At runtime, having x64 ODAC installed is enough. I can build an application that uses ODAC on my x86 dev machine (which has only x86 ODAC), dump it on an x64 box (with only x64 ODAC), and run it fine. For running the build, however, it seems I needed both x64 and x86 – Stealth Rabbi Feb 29 '12 at 14:52
  • 1
    ok, thanks for the info. I will revert my machine.config changes. – Ludwo Feb 29 '12 at 19:42
  • 1
    I'm having issues where our integration tests that test the new ODP implementation are running slower in Team City compared to when we ran the tests using System.Data.OracleClient. All other testing shows that ODP is significantly faster, except when running the integration tests. Any ideas? – Stealth Rabbi Mar 05 '12 at 13:27
  • I didn't noticed it on my server. I'm not using Team City. Try to execute integration tests in parallel as a workaround. – Ludwo Mar 06 '12 at 08:03