Skip to main content

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.DataAccess is in the GAC but the rule application uses the managed Oracle.ManagedDataAccess, or the installed version differs from the working servers.
note

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

  1. 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.

  2. Install and register ODP.NET using Oracle's tooling, not the GAC alone. ODP.NET is resolved by its invariant provider name through a DbProviderFactories entry in machine.config, in addition to residing in the GAC. Registering only into the GAC does not create that entry. Use Oracle's configure.bat (XCopy package) or OraProvCfg.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.dll

    Alternatively, deploy Oracle.ManagedDataAccess.dll into the application's bin directory and add the matching DbProviderFactories entry to the application's web.config/app.config.

  3. 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.