Oracle.DataAccess.dll在GAC中版本冲突的典型报错是System.IO.FileLoadException，提示“manifest definition does not match the assembly reference”，因GAC中存在PublicKeyToken相同但Version/Culture不匹配的多个版本；必须用gacutil逐条卸载所有版本并确认清空，bindingRedirect无效，推荐迁移到Oracle.ManagedDataAccess彻底规避GAC冲突。
Oracle.DataAccess.dll 在 GAC 中版本冲突的典型报错
直接表现是运行时抛出 system.io.fileloadexception，消息里带“could not load file or assembly 'oracle.dataaccess' or one of its dependencies”，后面紧跟着“manifest definition does not match the assembly reference”。这不是引用路径错了，而是 .net 加载器在 gac 里找到了一个版本，但你的程序集元数据要求另一个版本——两个 oracle.dataaccess.dll 的 publickeytoken 相同（都是 893fc270890156fa），但 version 和 culture 对不上。
清理 GAC 中所有 Oracle.DataAccess 版本的实操步骤
GAC 不支持“覆盖安装”，旧版本不手动删，新版本永远抢不到优先权。必须用 gacutil 逐个卸载，不能只删文件或靠重装 ODAC 蒙混过关。
- 先查清楚当前装了哪些：
gacutil -l Oracle.DataAccess—— 注意输出里每条记录的Version、Culture、PublicKeyToken - 逐条卸载（哪怕只差一个小版本号）：
gacutil -u "Oracle.DataAccess, Version=4.121.2.0, Culture=neutral, PublicKeyToken=893fc270890156fa" - 确认清空：
gacutil -l Oracle.DataAccess返回“未找到”才算成功 - 注意：如果用的是 64 位系统且项目目标平台是
x64，还得检查%windir%\Microsoft.NET\assembly\GAC_64；x86则看GAC_32；AnyCPU可能两边都得清
为什么不能靠 app.config bindingRedirect 解决
bindingRedirect 对 GAC 中的 Oracle.DataAccess 基本无效——ODP.NET 的设计让它绕过常规绑定策略。即使你写了：
<dependentAssembly> <assemblyIdentity name="Oracle.DataAccess" ... /> <bindingRedirect oldVersion="1.0.0.0-4.122.1.0" newVersion="4.122.1.0" /> </dependentAssembly>
运行时仍会按实际 GAC 中匹配的第一个“签名一致”的版本加载，redirect 不触发。这不是配置写错了，是 ODP.NET 自身的加载机制限制。
替代方案：改用 Oracle.ManagedDataAccess（推荐）
根本上避开 GAC 冲突，因为 Oracle.ManagedDataAccess.dll 是纯托管实现，不进 GAC，直接放 bin 目录或 NuGet 包里就能用，版本由项目自己控制。
- 卸载所有
Oracle.DataAccess相关组件（包括 Oracle Client） - NuGet 安装
Oracle.ManagedDataAccess（不是Oracle.ManagedDataAccess.Core，后者是 .NET Core 专用） - 代码里把
using Oracle.DataAccess.Client;换成using Oracle.ManagedDataAccess.Client; - 连接字符串不用改，但注意：
Oracle.ManagedDataAccess不支持TNSNAMES.ORA文件自动解析（除非显式调用OracleConfiguration.TnsAdmin）
真正麻烦的从来不是怎么删 GAC，而是删完之后发现项目里还有硬编码的 Oracle.DataAccess 类型、强类型 DataSet 或第三方组件依赖它——这些不会报 GAC 错，但会在运行时炸在第一次数据库访问上。
