Troubleshooting: Could not load assembly 'Oracle.ManagedDataAccess'
Symptom
When executing a rule application on a server, the rule engine raises an error similar to:
Source: RuntimeType
Message: Could not load assembly 'oracle.manageddataaccess' from '' / bin-search-path / GAC
This commonly appears on a newly provisioned server while existing servers run the same rule applications without error.
Cause
InRule loads the Oracle Data Provider for .NET (ODP.NET) dynamically at runtime, by assembly name, and only when a rule application exercises an Oracle feature, for example a database schema import, a SQL query or database endpoint targeting Oracle, or an irVerify override against an Oracle source. Because the provider is loaded by reflection, a rule application that references Oracle compiles and loads fine until the moment the Oracle provider is needed. At that point the engine must resolve the exact ODP.NET assembly and version it expects.
ODP.NET is not included in the InRule installer. It is a customer-supplied prerequisite that must be present and registered on every server where Oracle connectivity is used. A new server therefore needs the same ODP.NET provider, at a matching version, that your working servers have.
The error can be raised in two situations:
- The expected ODP.NET assembly is not installed or registered on this server.
- A different driver or version is present than the one the engine requests. For example, the unmanaged
Oracle.DataAccessis in the GAC but the rule application uses the managedOracle.ManagedDataAccess, or the installed version differs from the working servers.
If a rule application on the server does not use Oracle at all, this provider is not required. Seeing this error means an Oracle endpoint or query is being exercised. Confirm which rule application triggers it before installing the driver.
Resolution
-
Identify the provider and version on a working server. Determine whether your rule applications use the managed provider (
Oracle.ManagedDataAccess.Client) or the unmanaged provider (Oracle.DataAccess.Client), and the exact assembly version. Standardize the new server on the same provider and version. -
Install and register ODP.NET using Oracle's tooling, not the GAC alone. ODP.NET is resolved by its invariant provider name through a
DbProviderFactoriesentry inmachine.config, in addition to residing in the GAC. Registering only into the GAC does not create that entry. Use Oracle'sconfigure.bat(XCopy package) orOraProvCfg.exe, which perform both steps:OraProvCfg.exe /action:gac /providerpath:Oracle.ManagedDataAccess.dll
OraProvCfg.exe /action:config /product:odpm /frameworkversion:v4.0.30319 /providerpath:Oracle.ManagedDataAccess.dllAlternatively, deploy
Oracle.ManagedDataAccess.dllinto the application'sbindirectory and add the matchingDbProviderFactoriesentry to the application'sweb.config/app.config. -
Add or align the assembly binding redirect so the version the engine requests maps to the version you installed, matching your working servers. See .NET Framework Runtime Config Settings With InRule.
Related Topics
- .NET Framework Runtime Config Settings With InRule: Oracle assembly binding redirect.
- Schemas: at runtime, assemblies are searched in the binaries, the GAC, and the EndPointAssemblies subdirectory.
- EndPoint Assemblies Folder
- Before You Begin: supported databases and server prerequisites.