Could not load file or assembly 'Oracle.DataAccess' - Markup View

I am having a strange problem since installing the latest version of ODAC, 11.2.0.2.1. I installed both the 32-bit and 64-bit versions because I develop applications for both architectures. My computer is Win 7 64-bit.

Since installing ODAC and referencing the new 64-bit version of ODP.NET, one of my web applic开发者_Python百科ation projects in Visual Studio 2010 gives the following warning for all aspx pages and masterpages when I view them in Markup View.

ASP.NET runtime error: 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.

The warning is limited to Markup View. The web application builds and runs fine. I tried cleaning the VS Temporary ASP.NET Files, but that did not fix the issue. I removed all references to Oracle.DataAccess throughout my application, and then readded them to be sure that all the references were correct. The web app is compiled to 'Any CPU' but it uses the 64-bit Oracle.DataAccess. I created a new project, and referenced the same projects and dlls, and I do not get the warning, so it appears to be specific to this project file.

Any ideas why I would get the warning when in Markup View?

---

Expressly set the "Platform target" to "x86" or "x64" in the project properties --> Build tab.

Do NOT set it to "Any CPU." This is one of many common conditions which causes this driver of typical Oracle software quality to have a nervous breakdown.

---

Turns out the ODAC 11.2.0.2 xcopy installer doesn't correctly register all of the dlls (See bottom answer). As a result, Oracle.DataAccess.dll (64bit) was being copied into the BIN directory, and VS was trying to load it when in Markup View causing the warning. After manually registering the missing DLLs and rebooting, I am no longer having the problem.

---

Ideas you can check:

• Check the Oracle.DataAccess reference in your Visual Studio project has the 'Specific Version' property set to 'False' (this is not the default).
• Use the Fuslogvw.exe to determine what are the locations the .NET Framework is trying