ORA-12154在.NET中主因是Oracle.ManagedDataAccess默认不读tnsnames.ora，须显式配置TNS_ADMIN且路径无空格/中文、编码无BOM，或直接使用完整连接串如data source=localhost:1521/orclpdb1;。
ora-12154 不是网络连不通，而是 .net 应用根本没找到或没正确解析 tns 别名 —— 大多数情况下，删掉 tnsnames.ora 反而更稳。
tnsnames.ora 在 .NET 里基本不生效
Oracle 官方明确说明：tnsnames.ora 默认只被 Oracle 客户端工具（如 sqlplus、PL/SQL Developer）读取；Oracle.ManagedDataAccess（.NET 主流驱动）完全不加载它，除非手动设置环境变量 ORACLE_HOME 和 TNS_ADMIN。但即便设了，也常因路径权限、大小写、BOM 头等问题静默失败。
- 检查你是否真在用 TNS 别名：连接字符串形如
data source=ORCL;或data source=(DESCRIPTION=...)才会触发 tns 解析；若用的是data source=localhost:1521/orclpdb1;，压根不走 tnsnames.ora - Visual Studio 调试时，
TNS_ADMIN环境变量对当前进程无效，必须在项目属性 → “调试” → “环境变量”里显式添加，或改用完整连接串 - Windows 下路径含空格或中文时，
TNS_ADMIN极易失效；建议把tnsnames.ora放到C:oracle et这类纯英文无空格路径，并确认文件编码为 ANSI 或 UTF-8 无 BOM
连接字符串该用 service_name 还是 sid？
Oracle 12c+ 默认启用多租户（CDB/PDB），老式 sid（如 ORCL）通常指向 CDB 根，而应用应连 PDB 的 service_name（如 orclpdb1）。连错就报 ORA-12154 或 ORA-12505。
- 查服务名：用 sqlplus 登录后执行
SELECT value FROM v$parameter WHERE name = 'service_names'; - .NET 推荐格式：
data source=localhost:1521/orclpdb1;user id=scott;password=tiger;（注意双斜杠和斜杠的区别） - 若必须用 sid（如 Oracle 11g 单机），格式应为
data source=localhost:1521:ORCL;（冒号结尾），且确保监听器listener.ora中SID_LIST明确注册了该 SID - localhost 在 Docker 或 hosts 绑定异常时不可靠，换成
127.0.0.1或真实 IP 更稳
驱动版本与连接串格式必须匹配
Oracle.ManagedDataAccess 从 18c 开始弃用 sid 形式，强制要求 //host:port/service_name；低版本（如 12.1）仍支持 host:port:sid，但混用会静默失败。
- NuGet 包必须用官方源：
Oracle.ManagedDataAccess（不是旧的System.Data.OracleClient，后者已废弃） - 避免同时引用
Oracle.ManagedDataAccess和Oracle.DataAccess（ODP.NET 非托管版），二者冲突会导致连接初始化阶段就跳过 TNS 解析逻辑 - 检查 GAC 或 bin 目录是否残留旧版 DLL；可通过 Process Monitor 监控
tnsnames.ora文件是否被实际打开 - 连接字符串中不要加多余空格，例如
data source = ...中的等号两侧空格可能被某些版本驱动截断
tnsping 和 sqlplus 成功 ≠ .NET 能连
tnsping ORCL 只验证本地 tnsnames.ora 可读 + 监听器可达，不验证用户权限、服务名拼写、字符集兼容性；sqlplus user/pass@ORCL 成功，只说明客户端工具链完整，不代表 .NET 驱动复用了同一套解析逻辑。
- 最简排查法：把
tnsnames.ora重命名为tnsnames.ora.bak，改用完整连接串再试 —— 若通了，说明之前是 tns 配置干扰而非缺失 - 启用 ODP.NET 日志：
OracleConfiguration.TraceLevel = 2;+ 设置TraceFileLocation，日志里会明确写出“TNSNAMES adapter not used”或“Resolved using TNSNAMES” - 若用 Entity Framework，确保连接字符串写在
appsettings.json里时，JSON 反序列化未吞掉斜杠（如"data source": "localhost:1521\/orclpdb1"中的双反斜杠需转义）
真正卡住的地方往往不是配置本身，而是 .NET 驱动默认绕过了 tnsnames.ora，却有人硬要把它塞进部署包里，还指望它自动生效 —— 这种预期和现实的偏差，比语法错误更难定位。
