简介ODAC122010Xcopy-x64.zip 是面向 .NET 开发者的 64 位 Oracle 数据访问组件合集适合在 ASP.NET、服务端程序及 OLE DB 场景中连接 Oracle 12.2 数据库覆盖 ODP.NET、ASP.NET Providers 与事务服务等集成需求。压缩包共 179 个文件、约 73.48MB包含 67 个 dll 运行时组件以及 sql、plb、ora 脚本config、exe、bat 安装配置文件和 htm、txt 说明文档。已有 1545 人学习下载对仍维护 .NET Framework 4/2.0 项目的读者较有参考价值。借助其中的 Instant Client 与各 Provider可快速核对 64 位部署文件排查程序集加载、连接配置和分布式事务协调问题降低版本收集与匹配成本。1. 内网服务器不许装数据库客户端这套 xcopy 包就是那条备用路径给一台不允许运行安装向导的服务器补上数据访问能力是 ASP.NET 老项目经常撞上的场景站点跑在 .NET Framework 4 上要连 Oracle代码里既有Oracle.DataAccess.Client也有几段十年没动过的OraOLEDB.Oracle.1还有一处事务要用到 Oramts。正常做法是装一个客户端但机器策略不允许安装程序一跑就被拦。ODAC122010Xcopy-x64.zip走的是另一条路解压、复制、跑一个批处理把 odp.net4、oledb、oramts、asp.net 这几组 DLL 铺到指定目录再按需写注册表和 machine.config。它解决的不是“性能更好”而是“这台机器上根本没有安装程序可用”。适合手上维护着 .NET Framework 老站、又不能动系统安装包的从业者如果你的项目是 .NET Core / .NET 6直接引 NuGet 上的托管驱动就行这套东西反而多余。2. 拆包先认人五个子目录与 odp.net4、oledb、oramts 的对应关系压缩包解开之后不要急着跑批处理先花五分钟把目录和 DLL 对上一遍。这个包里同时躺着好几代驱动名字相近、版本号相近认错了就是后面几小时的排查。先把对应关系列清楚再决定装哪几组。2.1 目录结构与各组件的归属解压后的顶层一般能看到odp.net、asp.net、oledb、oramts几个目录外加install.bat、configure.bat和一份 readme。下面这张表是我自己核对时用的映射实际文件名以包内为准但归属关系不会变目录关键文件对应技术栈部署时要动什么odp.net\bin\4Oracle.DataAccess.dll、oci.dll、oraociicus*.dllODP.NET 非托管驱动程序集版本 4.122.1.0进 GAC 写HKLM\SOFTWARE\Oracle\ODP.NET\4.122.1.0odp.net\bin\2.x同名的 2.x 版本老 .NET Framework 2.0/3.5 项目同上注册表键为 2.122.1.0odp.net\managedOracle.ManagedDataAccess.dll纯托管驱动不依赖 oci.dll复制即可通常随站点 bin 目录走asp.net\binOracle.Web.dllASP.NET 成员资格、角色、会话状态提供程序复制 改 machine.configoledb\binOraOLEDB*.dllOLE DB 提供程序OraOLEDB.Oracle.1COM 注册 写 Provider 注册表项oramts\binoraMTS.dll、Oracle.Services.For.MTS相关文件分布式事务资源管理器COM 注册 配合 MSDTC表格里最容易被忽略的是oci.dll这一列。odp.net4 和 oledb 两组都各自带了一份 oci 相关的动态库它们不是摆设——非托管驱动最终要靠它跟数据库通信。所以部署时这两组目录不能只挑 DLL 拷得整目录带过去。2.2 odp.net4 和 2.x 的分界别按“新”来选按框架版本来选很多人一看有 4就觉得统统上 4。实际判断标准只有一个引用方的程序集版本。.NET Framework 4.0 及以上编译出来的项目引用的是Oracle.DataAccess, Version4.122.1.02.0/3.5 时代编译的老程序集引用的是2.122.1.0。这两个版本号是硬绑定CLR 加载时对不上就是FileLoadException或者一个更含糊的“无法加载文件或程序集”。所以一个站点里如果同时有 Framework 4 的主站和一个老的 2.0 工具库两组都得铺不能只装一组。托管驱动Oracle.ManagedDataAccess是另一套逻辑它不注册 GAC、不写 ODP.NET 注册表键直接放进站点的bin目录就能用程序集版本是 4.122.1.0 那一条线。缺点是它和Oracle.DataAccess的类型不能混用命名空间虽然像但是两个不同的程序集OracleConnection不是同一个类型。老代码里写死的Oracle.DataAccess.Client改造成本是有的这也就是为什么很多人最后还是回到非托管这条路。2.3 oledb 为什么还在不是所有老代码都改得动OraOLEDB.Oracle.1在这个包里占的比重不小原因很现实一堆十几年前的 ASP 页面、VBScript 脚本、Excel 宏、SSIS 包连接串里写的就是ProviderOraOLEDB.Oracle.1。这些代码没人敢动也找不到原始负责人重写成 ODP.NET 的成本远高于把驱动补上。OLE DB 提供程序是 COM 组件跟 .NET 程序集的部署方式完全不同。它要靠regsvr32注册到注册表的 CLSID 下还要在HKLM\SOFTWARE\Classes\OraOLEDB.Oracle里写 Provider 的友好名和 CLSID 映射。install.bat 会替你干这件事手工部署时这一步最容易漏漏了之后的报错是“未在本地计算机上注册 OraOLEDB.Oracle.1 提供程序”看着像驱动没装其实是 COM 没登记。2.4 oramts只在真的需要分布式事务时才装oramts 对应的是 Oracle Services for MTS作用是让 Oracle 连接能作为资源管理器参与 MSDTC 协调的分布式事务。典型场景是一个方法里同时操作 Oracle 和 SQL Server并且要求两边一起提交或回滚。这一组文件不装普通事务照跑不误只有TransactionScope里跨库操作才会出问题。所以部署策略上我一般把它单独拎出来先确认业务里真有跨库事务再装。装了之后还要确认 MSDTC 的配置否则一样报错——这个在后面第 5 章会展开。3. 免安装部署实操install.bat 与手工搬迁两条路认完目录就可以动手了。有两条路一是让包里的install.bat一把梭二是自己控制每一步拷贝和注册。前者快适合有管理员权限、目标目录可以随便定的机器后者慢但每一处改动都清楚出问题时知道从哪退回去。3.1 用 install.bat 一次铺开以管理员身份打开命令提示符进解压目录执行下面这条:: 切到解压后的根目录按实际路径改 cd /d D:\pkg\ODAC122010Xcopy-x64 :: 第一个参数是组件all 表示全部第二个参数是目标目录 install.bat all C:\oracle\odac12c :: 如果上一步只做了文件复制再单独执行配置 configure.bat allinstall.bat的第一个参数接受组件名常见取值是all、odp.net4、odp.net2、asp.net、oledb、oramts第二个参数是目标根目录路径里别带空格和中文能省掉一堆麻烦。它的动作是把对应目录的文件复制过去进 GAC 的注册程序集写 ODP.NET 的DllPath键注册 OLE DB 的 COM 组件并在 machine.config 里插入 ASP.NET 提供程序的配置节。configure.bat是“只做配置、不拷文件”的那一半参数同样支持all和组件名后面可以再跟一个 machine.config 的路径来指定要改哪个文件。我习惯把它单独跑一次原因很简单批处理里任何一步失败整体退出码不一定是非零分开跑能看出是哪一段没成功。目标目录建议统一成C:\oracle\odac12c这种结构不要塞进Program Files。一是路径里的空格在部分老脚本里会出问题二是后面要写进注册表和 PATH 的路径越短越好排查时肉眼比对也方便。提示install.bat 修改 machine.config 之前会备份原文件扩展名通常带.bak或时间戳。部署完成后先确认备份存在再继续后面的步骤。3.2 不让动系统目录时的手工部署有些机器连C:\oracle都不让写只能放到应用自己的目录下比如D:\app\odac。这时候 install.bat 的全自动流程会失败一半得手工来。核心是四件事拷文件、注册程序集、写注册表、加环境变量。先拷文件按组件分组拷别整包乱铺:: 非托管 ODP.NET 4连同目录里的 oci 相关 DLL 一起 xcopy /E /I /Y D:\pkg\ODAC122010Xcopy-x64\odp.net\bin\4 D:\app\odac\odp\4 :: OLE DB 提供程序 xcopy /E /I /Y D:\pkg\ODAC122010Xcopy-x64\oledb\bin D:\app\odac\oledb :: ASP.NET 提供程序 xcopy /E /I /Y D:\pkg\ODAC122010Xcopy-x64\asp.net\bin D:\app\odac\aspnet/E连空目录一起拷/I让目标被当成目录而不是文件/Y覆盖时不问。这三件事在一台要反复重装的测试机上能省很多次回车。然后是注册表和程序集。程序集进 GAC 需要gacutil一般随 SDK 或 VS 的命令行环境提供:: 把非托管驱动注册进 GAC gacutil /i D:\app\odac\odp\4\Oracle.DataAccess.dll :: 写 ODP.NET 的 DllPath让运行库能找到同目录的 oci reg add HKLM\SOFTWARE\Oracle\ODP.NET\4.122.1.0 /v DllPath /t REG_SZ /d D:\app\odac\odp\4 /freg add里的键名4.122.1.0必须和程序集版本严格对应写错一个数字驱动就找不到自己的依赖报错是运行时的DllNotFoundException而不是安装期的提示。/f表示已存在就覆盖重装时要用。64 位系统上还有个坑32 位进程读的是HKLM\SOFTWARE\WOW6432Node\Oracle\...这条路径。用 64 位包部署、却让 32 位应用程序池去跑注册表就写到了另一棵树上两边对不上。判断方法见 3.3。最后是 TNS 相关。TNS_ADMIN指向放着tnsnames.ora、sqlnet.ora的目录:: /M 表示写系统级环境变量需要管理员权限 setx /M TNS_ADMIN D:\app\odac\network\adminsetx /M只影响之后新起的进程已经开着的 IIS 应用池不会感知到改完必须回收应用池或者iisreset。这一点在排查“命令行能连、站点连不上”时特别关键。3.3 验证部署四个检查点按顺序过装完别急着让业务去试自己先把四个点过一遍出问题能立刻定位到层。第一个点GAC 里有没有这个程序集:: 列出 GAC 中所有 Oracle.DataAccess看版本号 gacutil /l Oracle.DataAccess输出里要能看到4.122.1.0那一条并且路径指向你刚指定的目录。如果只有旧版本说明前面gacutil /i没成功或者被同名旧程序集挡住了。第二个点运行库能不能按版本号加载到它# 按完整程序集名加载成功会打印程序集全名和位置 [System.Reflection.Assembly]::Load(Oracle.DataAccess, Version4.122.1.0, Cultureneutral, PublicKeyToken89b483f429c47342) | Select-Object FullName, Location这条命令在 PowerShell 里跑注意位数要跟你的目标进程一致64 位进程用 64 位 PowerShell32 位进程用SysWOW64下的那个。加载成功但Location指向一个你没预期的目录那就是 GAC 里存在同版本的另一份属于后面第 5 章要处理的情况。第三个点注册表键的DllPath对不对reg query HKLM\SOFTWARE\Oracle\ODP.NET\4.122.1.0 /v DllPath值应该等于 3.2 里写进去的目录。如果这里指向了旧的客户端安装目录运行时会去那儿找 oci然后加载到不匹配的版本。第四个点最小连接测试。写一个十行的控制台程序或者直接用 PowerShell 加载驱动连一次连接串里显式带上Data Source先别用 EZConnect 之外的别名排除 tnsnames 的干扰。四个点都过再让站点去引。4. ASP.NET 站点接入machine.config、web.config 与 Oracle.Web 的配置顺序驱动铺好了接下来是让站点用上。这一步的顺序很重要先改 machine.config 注册提供程序再改 web.config 引用最后调权限。反过来做中间任何一步出错都会得到一个看不出根因的异常。4.1 Oracle.Web 在 machine.config 里的位置Oracle.Web.dll提供的是 Membership、Role、Profile、SessionState 这几类 Provider它们要被 ASP.NET 的 Provider 模型识别必须在 machine.config 的system.web节里登记。configure.bat 的asp.net选项做的就是这件事它会往membership、roleManager、profile、sessionState里各插一段。如果机器上跑着多个站点、只有一个要用 Oracle 的提供程序我倾向于不动 machine.config改在站点自己的 web.config 里写完整定义。原因很实际machine.config 是全局的改坏了所有站点一起挂而且回滚要靠备份文件手工还原。web.config 出问题最多影响一个应用删掉重启就好。4.2 web.config 的连接串与 Provider 定义下面这段是一个最小可用的配置把连接串和成员资格提供程序都写在站点级configuration connectionStrings !-- providerName 必须和实际使用的驱动对上非托管写 Oracle.DataAccess.Client -- add nameOraAspNetConString connectionStringUser Idapp;Password***;Data SourceORCLPDB;Poolingtrue;Min Pool Size1; providerNameOracle.DataAccess.Client / /connectionStrings system.web membership defaultProviderOracleMembershipProvider userIsOnlineTimeWindow15 providers add nameOracleMembershipProvider typeOracle.Web.Security.OracleMembershipProvider, Oracle.Web, Version4.122.1.0, Cultureneutral, PublicKeyToken89b483f429c47342 connectionStringNameOraAspNetConString applicationName/ enablePasswordRetrievalfalse enablePasswordResettrue requiresQuestionAndAnswerfalse requiresUniqueEmailfalse passwordFormatHashed maxInvalidPasswordAttempts5 minRequiredPasswordLength8 / /providers /membership /system.web /configurationtype属性里的四段式程序集名不能省程序集名、版本、区域、公钥标记少一段就会走到“按简单名加载”的宽松匹配上可能加载到别的版本。connectionStringName要和上面connectionStrings里的name完全一致大小写敏感。applicationName决定数据行的归属多个站点共用一个库时这一项写错会导致用户互相看不见排查起来非常费劲。passwordFormat选Hashed之后enablePasswordRetrieval必须是false两个参数是联动的配错会在站点启动时直接抛配置异常。4.3 应用程序池标识与目录权限驱动文件和配置文件都就位了还有一个经常被忘的环节应用程序池用哪个身份跑那个身份就得能读到部署目录和注册表键。默认的ApplicationPoolIdentity是一个虚拟账户对D:\app\odac这种自建目录通常没有读权限。表现是站点启动时报“拒绝访问”或者提供程序初始化失败异常堆栈指向配置文件加载看着像配置错其实是权限问题。给权限的方式是给对应的虚拟账户授权而不是给Everyone:: 给应用程序池虚拟账户读执行权限池名按实际改 icacls D:\app\odac /grant IIS APPPOOL\YourAppPool:(OI)(CI)RX /T(OI)(CI)表示继承到子文件和子目录RX是读加执行。加完回收应用池再试。这一步在测试机上经常被跳过因为测试时用的是管理员身份跑的控制台程序权限天然是够的一上 IIS 就翻车。4.4 两条通路的代码验证配置改完用一小段代码把 ODP.NET 和 Oracle.Web 各验一遍using System; using Oracle.DataAccess.Client; // 非托管驱动命名空间 using Oracle.Web.Security; // Oracle.Web 提供程序 class Probe { static void Main() { // 通路一直接用 ODP.NET 打开连接确认驱动与 oci 都正常 string cs User Idapp;Password***;Data SourceORCLPDB;Poolingtrue;; using (var conn new OracleConnection(cs)) { conn.Open(); using (var cmd new OracleCommand(select 1 from dual, conn)) { Console.WriteLine(ODP.NET OK: cmd.ExecuteScalar()); } } // 通路二通过 Oracle.Web 的提供程序创建用户确认 Provider 配置生效 var provider Membership.Provider as OracleMembershipProvider; if (provider null) throw new InvalidOperationException(默认成员资格提供程序不是 Oracle 实现); MembershipCreateStatus status; provider.CreateUser(probe_user, Pssw0rd!, probeexample.com, null, null, true, null, out status); Console.WriteLine(Oracle.Web status: status); } }第一段验证的是驱动层能连上、能执行说明Oracle.DataAccess.dll、oci 依赖、TNS_ADMIN三者都对。第二段验证的是配置层Membership.Provider拿到的类型不对说明 web.config 里的type或defaultProvider有问题拿到了但CreateUser抛异常通常是表结构没初始化或者连接串指向的库不对。这里用as转换而不是强转是为了在类型不匹配时给出一个能看懂的异常而不是一个笼统的InvalidCastException。做部署验证时错误信息本身就是排查的一半。5. 避坑与排查五类翻车现场的现象、成因与处置部署这套包踩过的坑八成集中在下面五类。每一条我都按“看到什么、为什么、怎么办”写方便对着报错直接查。5.1 BadImageFormatException位数不匹配现象站点一访问就抛BadImageFormatException提示“试图加载格式不正确的程序”堆栈停在加载Oracle.DataAccess那一行。原因应用程序池开启了 32 位兼容Enable 32-Bit Applications True进程是 32 位的但装的是 x64 的 xcopy 包GAC 里只有 64 位程序集。反过来也成立64 位进程加载了 32 位驱动。解决先确认应用池的位数设置再决定装哪个包。要么把应用池改成 64 位并确认没有其他 32 位依赖要么另外找 32 位包铺一份。两个都装也行但注册表得分开写32 位进程读WOW6432Node那棵树GAC 视角也不同这一点在 3.2 里提过。5.2 加载到旧版本GAC 里躺着同名程序集现象代码明明按 4.122.1.0 编译运行时却报方法不存在或者行为异常用Assembly.Load打印Location发现指向了一个旧的客户端安装目录。原因机器上原本装过数据库客户端或者更早的 ODACGAC 里有同名的Oracle.DataAccess。GAC 的查找规则优先匹配版本但如果 web.config 里配了bindingRedirect或者引用的版本被合并过就会加载到旧的那份。更隐蔽的是DllPath指向旧目录oci 版本和新驱动不匹配表现为连接时崩溃而不是加载时崩溃。解决gacutil /l Oracle.DataAccess列出全部副本逐个比对版本和路径确认后卸载不用的版本或者在 web.config 里显式写bindingRedirect把旧版本重定向到新版本。DllPath键也要一起核对别只改一半。5.3 ORA-12154 / ORA-12541找不到连接描述符现象命令行用 sqlplus 能连站点连不上报ORA-12154: TNS: 无法解析指定的连接标识符或者报ORA-12541: TNS: 无监听程序。原因前者的九成是TNS_ADMIN没生效——改了系统变量但应用池没回收进程里还是旧值或者tnsnames.ora放在了驱动自带的network\admin下而实际生效的是另一个目录。后者多半是连接串里的主机端口写错或者服务端监听确实没起。解决先在应用池的身份下确认环境变量别用你自己的登录会话去看。临时验证可以在 web.config 的连接串里直接用 EZConnect 写法host:port/service_name绕开 tnsnames能连就说明是解析问题而不是网络问题。定位清楚再决定是修TNS_ADMIN还是修别名文件。5.4 OraOLEDB.Oracle.1 未注册COM 没登记现象老的 ASP 页面或者 SSIS 包报“未在本地计算机上注册 OraOLEDB.Oracle.1 提供程序”。原因文件拷过去了但 COM 组件没注册或者注册了但位数不对32 位进程找不到 64 位的注册项。解决用管理员权限对OraOLEDB*.dll执行regsvr3232 位组件要用SysWOW64\regsvr32.exe。注册完在注册表里确认HKLM\SOFTWARE\Classes\OraOLEDB.Oracle下的 CLSID 指向正确路径。注意 OLEDB 提供程序依赖 oci整目录拷贝别只挑一个 DLL。5.5 Oramts 装了还是事务失败MSDTC 没配现象TransactionScope里同时操作两个库提交时报分布式事务相关的错误或者干脆超时。原因oramts 只是让 Oracle 连接能参与分布式事务真正的协调者是 MSDTC。MSDTC 未开启网络 DTC 访问、未允许入站/出站、防火墙挡了 RPC 端口都会让事务在提升阶段失败。另外连接串里如果没开enlist连接根本不会自动登记到事务里。解决先确认连接串行为再检查 MSDTC 的安全配置网络 DTC 访问、事务管理器通信、入站出站授权最后看防火墙。这一条排查链路长我一般从“能不能只用本地事务”倒推如果业务允许把跨库操作拆开能省掉整条链路的不确定性。6. 版本共存与回滚把这次部署做成可撤销的一步部署这套东西最容易留下的隐患不是装不上而是装完之后没法干净地退回去。GAC 里的程序集、注册表键、machine.config 的改动、COM 注册四样东西分散在四个地方出问题时想还原得靠记忆。我现在做这类部署会强制留一份可撤销的清单。先做备份四样东西各存一份对象备份方式还原命令GAC 程序集记录gacutil /l的输出存成文本gacutil /u Oracle.DataAccess,Version4.122.1.0,...ODP.NET 注册表键reg export导出整个Oracle\ODP.NET子树reg import odac_backup.regmachine.config复制一份带日期的副本直接覆盖回原路径OLE DB COM 注册记录 CLSID 和 DLL 路径regsvr32 /u反注册导出注册表这一步用一行命令就够:: 部署前导出出问题一条命令还原 reg export HKLM\SOFTWARE\Oracle\ODP.NET D:\backup\odpnet_before.reg /y reg export HKLM\SOFTWARE\Classes\OraOLEDB.Oracle D:\backup\oledb_before.reg /y/y覆盖同名文件路径提前建好。等真出事的时候你不会有心情去找“备份到底存哪了”。版本共存的处理上我的做法是同一台机器只保留一条主线。要么全用非托管Oracle.DataAccess4.122.1.0要么全用托管Oracle.ManagedDataAccess不要在一个应用里混。混用的直接后果是类型不兼容OracleConnection来自两个不同程序集编译期不报错、运行期转换失败。如果确实有老代码改不动就让它单独跑在一个应用池里用旧版本跟新站物理隔开。还有一个验证习惯值得养成部署完成后在测试机上跑一次“断开再连”的完整流程而不是只用一条select 1 from dual验证。具体做法是把应用池停掉、清空连接池、再启动然后走一遍登录和一次跨库事务。连接池里残留的旧连接会掩盖掉很多问题只有重启之后第一次建连才暴露真实的配置状态。最后说个我自己的教训。早些年做这类 xcopy 部署我图省事直接在机器上跑install.bat all跑完就交付了。两个月后那台机器要升级运维问我“当初改了哪些地方”我翻不出任何记录只能对着注册表和 machine.config 一点点比对花了整整一个下午。从那以后我每次做 xcopy 部署都强制走一遍“先导出注册表、再跑批处理、最后记一份变更清单”的流程清单里连目标目录和DllPath的值都写清楚。慢十分钟省一下午。希望帮到你。本文还有配套的精品资源点击获取