Cannot obtain Oracle Client information from registry - but connects fine in unit test

Discussion of open issues, suggestions and bugs regarding ADO.NET provider for Oracle
Post Reply
Nihimon
Posts: 4
Joined: Fri 03 Mar 2017 18:09

Cannot obtain Oracle Client information from registry - but connects fine in unit test

Post by Nihimon » Fri 03 Mar 2017 18:27

I'm using NuGet package "dotConnect.Express.for.Oracle" version 9.2.200 for a web api solution.

In my unit tests, I'm able to successfully connect to database. When running api, I get an error: Cannot obtain Oracle Client information from registry.

I read an old thread from 2008 about solutions to this, but they don't seem to apply. Specifically, the web.config file at Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config has the following:

Code: Select all

    <location allowOverride="true">
        <system.web>
            <securityPolicy>
                <trustLevel name="Full" policyFile="internal"/>
                <trustLevel name="High" policyFile="web_hightrust.config"/>
                <trustLevel name="Medium" policyFile="web_mediumtrust.config"/>
                <trustLevel name="Low" policyFile="web_lowtrust.config"/>
                <trustLevel name="Minimal" policyFile="web_minimaltrust.config"/>
            </securityPolicy>
            <trust level="Full" originUrl=""/>
        </system.web>
    </location>
And my local web.config doesn't override any of this.

Obviously, since the connection is able to be opened when I'm running a unit test, it has to be something with IIS or my web api configuration, but the NuGet Package "Oracle.ManagedDataAccess" version 12.1.24160 works fine with our existing configuration.

I noticed there was a new version of dotConnect for Oracle available, so I updated my package to 9.2.220, but I'm still getting the same error.

Nihimon
Posts: 4
Joined: Fri 03 Mar 2017 18:09

Re: Cannot obtain Oracle Client information from registry - but connects fine in unit test

Post by Nihimon » Fri 03 Mar 2017 20:18

It looks like setting "Enable 32-Bit Applications" to "True" in IIS solved this problem.

Post Reply