When I install the Oracle Data Access Client 126.96.36.199.20 32 bit on my build server, I see the .Net 2.0 framework versionof the oracle.dataaccess.dll in the GAC? Why is that? How can I get the .NET 4.0 version installed. What are the differences if I use one or the other?
If you have .NET 4 Framework installed, the ODAC installer should install and GAC ODP.NET for .NET 4 as well.
Can you check whether ODP.NET for .NET 4 is on your machine. It should be in this directory:
ODP.NET for .NET 2.0 is intended for the .NET 2.x and 3.x runtimes. ODP.NET for .NET 4 is intended for .NET 4 and higher releases. Microsoft introduces new features to the ADO.NET spec ever few major releases, which is why there are separate versions.
Ok, I'm a little bit confused. The issue that I getting and the reason I posed this question in the first place is because when I build a project via TFS Team Build I get the following error:
+ASPNETCOMPILER : error ASPCONFIG: Could not load file or assembly 'Oracle.DataAccess' or one of its dependencies. An attempt was made to load a program with an incorrect format. [D:\Builds\9\test\V2.0\Sources\Source\Solution\UI_1.metaproj]+
When I create project references in Visual Studio for projects and select the >NET tab, it says filtering for .NET 4.0 and show me a version of the assembly 188.8.131.52 which appears to be a .NET 2.0 version. When I look in the folder C:/windows/assembly, I can see this version. When I go into the folder C:\windows\Microsoft.Net\assembly\GAC_32 I can see a version 184.108.40.206 version. The root issue is the fact that when I build my solution via Team Build, the aspnet_compile fails due to this assembly. I'm assuming that it has something to do with the assembly .NET version reference mismatch.
Why do I see the 220.127.116.11 assembly in the windows\]assembly folder and the other version in the GAC_32 folder? Is this the root cause of my error?
I'm not sure why Visual Studio is doing that. You could try adding it by browsing to the .net 4 DLL instead of trying to find in the Visual Studio list, and see if that fixes it.
That said, "load a program with an incorrect format" is an error that also appears due to platform mismatches. Make sure your build is running in x86, not in AnyCPU (the default) or x64. With the latter two, it'll try to load a 64-bit version of the assembly and will fail with that error.
The build is running ANY CPU/Debug on a 64 bit machine. when I read about running applications on a 64 bit machine, I read something that says
"On a 64 bit machine:
ANY CPU: runs as a 64-bit process, can load Any CPU and x64 assemblies, will get a BadImageFormatException if it tries to load an x86 assembly"
The msbuild appears to build with a 32 bit oracle.dataaccess.dll reference and the aspnet_compiler may be complaining that it cannot load the 32-bit version. So if I build it as Any CPU on a 64 bit machine, it builds an assembly that can be run on either a 64 bit machine or a 32 bit machine. Does it have something to do with the fact that the aspnet_compiler is running the application on a 64 bit machine and attempts to load a 32 bit assembly?
If you build in AnyCPU, it's going to depend on what OS you're using as to what you end up with. If you do it in a 32 bit OS, you'll get a 32 bit program and that will load a 32 bit Oracle.DataAccess.dll and will work just fine.
If it's on 64 bit, you'll get a 64 bit program that wants to load a 64 bit Oracle.DataAccess.dll. Now, here is where the problem starts:
- If you have a 64 bit ODAC on the system of the same version as your reference, it'll load and work.
- If not, it'll load the 32 bit ODAC you have on the system and fail.
You can fix this by changing the build to x86, so that it always builds an x86 version no matter what the bit-ness of the OS. In that case you'll be able to use a 32 bit Oracle client everywhere and things should just work. Alternately installing a 64 bit 18.104.22.168 Oracle client (and making sure Copy Local = False on your reference) on the 64 bit system should also fix the problem.
Installing the 64 bit client did work. I guess I'm a little bit confused by the was aspnet_compiler works on the build server. I have other Web Application projects which do not run through aspnet_compiler and they build Any CPU and I did not have the oracle.dataacess.dll 64 bit loaded on the machine. It appears that the aspnet_compiler "loads" the assemblies and them complains about the 32-bit version that was previously the only on the server. So I was only seeing this issue when I build a Web Site project that publishes the assembly and not on Web Application projects.
Hopefully, that makes sense. It does appear to be a 32-it vs 64-bit version issue, I guess I'm curious why the aspnet_compiler runs into this issue and "msbuild" does not. Is it that when msbuild runs it does not actually load the assemblies, but merely open them up for inspection? I guess why the difference in behavior across the two project types (web site vs Web Application).
msbuild doesn't actually "run" the web application, so it's probably just checking if a matching reference is found (which it is). If you built it with msbuild and then tried to browse to it on a 64 bit server, you'd hit the problem at that point.
I'm guessing aspnet_compiler is precompiling the site for faster startup time, and possibly actually starting it too. So it's hitting the issue earlier.
Anyway glad we found a solution for you. Don't forget to mark an answer. :)