.NET Framework WinForms app crashing with Oracle.ManagedDataAccess when Oracle Client 19c (64 bit) is installed (duplicate config issue)

Aman Agrahari 220 Reputation points

Hi all,

Iā€™m encountering an issue after migrating my VB.NET Windows Forms application from unmanaged ODP.NET to managed ODP.NET, and Iā€™d appreciate your guidance.

Background

  • Application type: VB.NET Windows Forms (.NET Framework)

Earlier setup:

Platform: x86 (32-bit)

 Provider: **Oracle.DataAccess.dll (unmanaged ODP.NET)**

 
 Required Oracle Client installed on client machines

 
 Current setup:

 
 Platform: **x64 (64-bit)**

 
 Provider: **Oracle.ManagedDataAccess.dll (NuGet ā€“ managed driver)**

 
 No Oracle Client dependency expected
```---
### Issue Description

On machines **without Oracle Client**, the application works fine.

On machines with **Oracle Client 64-bit (19c)** installed:

 The application **crashes on startup**
 
```sql
 The issue appears related to **duplicate configuration entries** in the `.exe.config`
```---
### Relevant Config Entries

Below are examples of the entries present in my `.exe.config`:

**1. DbProviderFactories section:**


```xml
<system.data>
 <DbProviderFactories>
 <remove invariant="oracle.manageddataaccess.client" />
 <add name="ODP.NET, Managed Driver"
 invariant="oracle.manageddataaccess.client"
 description="..."
 type="..." />
 </DbProviderFactories>
</system.data>

2. Config section declaration:

<section name="oracle.manageddataaccess.client"
 type="OracleInternal.Common.ODPMSectionHandler,
 Version=4.122.23.1,
 Culture=neutral,
 PublicKeyToken=..." />

Key Observation

When I remove the Oracle-related entries from .exe.config, the application starts successfully.

This suggests a conflict between application-level config (from NuGet) and machine-level config (likely added by Oracle Client installation, e.g., machine.config or GAC).

Questions

Why does installing Oracle Client (19c) lead to duplicate configuration behavior for Oracle.ManagedDataAccess?

Does the Oracle Client installer register entries in machine.config that conflict with application config?

What is the recommended approach to avoid this issue?

Should I remove these sections from my .exe.config?

 Or keep only certain entries?

 
 Is there a way to safely override machine-level configuration?

 
 What is the **best practice for deploying a managed ODP.NET application** on systems that may already have Oracle Client installed?
```---
### Goal

I want my **x64 application using Oracle.ManagedDataAccess** to:

Run independently of Oracle Client

Work reliably on machines **with or without Oracle Client installed**

---
Any help or best practices would be greatly appreciated.

Thanks in advance!
0 comments No comments
Sign in to comment

Answer accepted by question author

Taki Ly (WICLOUD CORPORATION) 2,145 Reputation points ā€¢ Microsoft External Staff ā€¢ Moderator

Hello @Aman Agrahari ,

This might be happening because when Oracle Client 19c is installed, its installer appears to automatically configure machine-wide settings and the GAC. Because the .NET Framework generally loads machine.config first and checks the GAC before local assemblies, defining the oracle.manageddataaccess.client section again in your .exe.config likely triggers a duplicate section exception, causing the crash.

I would suggest some approaches to help your application run reliably regardless of the host machine's Oracle Client status:

  1. Remove the <section> declaration: Try deleting <section name="oracle.manageddataaccess.client"...> from your .exe.config entirely. Since the .NET Framework requires section names to be unique across the configuration hierarchy, removing it can help prevent the duplication error.
  2. Keep the <DbProviderFactories> tags: What you did here aligns with Microsoft's design. Using the <remove invariant="..." /> tag is the standard Microsoft .NET mechanism for clearing inherited collection settings to safely override machine-level configurations.
  3. Configure via code: If you rely on specific Oracle settings (like TNS_ADMIN), you might consider setting them programmatically using the OracleConfiguration class at application startup. Oracle provides this class specifically to handle settings in code, which can help decouple your app from XML files and any existing machine-level setups.

Disclaimer: Some links are non-Microsoft website. The pages appear to be providing accurate, safe information. Watch out for ads on the site that may advertise products frequently classifies as a PUP (Potentially Unwanted Products). Thoroughly research any product advertised on the site before you decide to download and install it.

I hope this helps with your question. If you found my response helpful, please follow this guide to provide feedback.

Thank you.

  1. Aman Agrahari 220 Reputation points

    Thank you for the explanation!!

    Yes, deleting the <section name="oracle.manageddataaccess.client" ...> entry from the .exe.config prevents the duplicate section error. However, I would like to confirm the actual purpose of this section and whether removing it permanently could cause any functional issues. In my case, the application packages tnsnames.ora as part of the installer.

    And I'm keeping <DbProviderFactories> tags since it safely overrides machine-level configurations.
    My goal is to ensure the application runs reliably on machines both with and without Oracle Client installed, without modifying machine.config.

  2. Taki Ly (WICLOUD CORPORATION) 2,145 Reputation points ā€¢ Microsoft External Staff ā€¢ Moderator

    Hi @Aman Agrahari ,

    Regarding your concern about the <section> tag's purpose and whether removing it permanently is safe:

    1. The purpose of the <section> tag

    According to Microsoft's documentation on Configuration Sections, the <section> tag simply specifies the configuration handler for a custom XML element. It tells the .NET runtime how to parse the custom <oracle.manageddataaccess.client> block if one exists later in your .exe.config.

    If you remove that Oracle configuration block from your XML and choose to handle settings programmatically instead, this XML parser definition is no longer needed. Therefore, removing it might not cause any functional issues for your app.

    2. Handling your packaged tnsnames.ora via code

    Since you are packaging tnsnames.ora with your installer, you can bypass XML configuration entirely. Based on the OracleConfiguration Class documentation, Oracle provides properties to set these values in your code.

    You can set the TNS_ADMIN path programmatically at the very beginning of your application startup. For example, if tnsnames.ora is in the same directory as your .exe:

    C# Example

    
Oracle.ManagedDataAccess.Client.OracleConfiguration.TnsAdmin = System.AppDomain.CurrentDomain.BaseDirectory;

    VB.NET Example

    
Oracle.ManagedDataAccess.Client.OracleConfiguration.TnsAdmin = System.AppDomain.CurrentDomain.BaseDirectory

    By using this code-based approach, your application dynamically locates its own tnsnames.ora file without relying on the .exe.config or machine.config. This appears to align with your goal of making the application reliable and independent of the host machine's Oracle Client installation.

    Hope this clears up the details for you.

Sign in to comment

2 additional answers

  1. Senthil kumar 685 Reputation points

    Hi Aman Agrahari,

    Please confirm your Visual studio version.

    • Go to project properties then go to compile
    • go to Target CPU select 'Any CPU' and tick Prefer 32 bit.
    • then try to run your application.

    šŸ‘ vs

    Thanks

    1. Aman Agrahari 220 Reputation points

      I have recently migrated my application from 32-bit to 64-bit and am using the Oracle Managed NuGet package (ODP.NET Managed Driver) in my project. The application is developed and built using Visual Studio 2022, and the installer is created using a VDPROJ setup project.

      However, I am facing a launch issue on machines where Oracle Client 19c is already installed. Interestingly, the application works perfectly fine on systems where no Oracle Client is installed.

      My requirement is to ensure that the application runs successfully regardless of whether an Oracle Client is present on the target machine. Since I am using the managed Oracle driver, it should ideally not depend on any locally installed Oracle Client.

      Feel free to ask more question.
      Thanks

    2. Senthil kumar 685 Reputation points

      Yes, I understand. the application will run from dependencies dll's so no need to install oracle driver in all machines.

    3. Aman Agrahari 220 Reputation points

      The client requires Oracle Client to be installed on the machine for other applications, so removing it is not an option. My goal is to ensure that my application runs successfully regardless of whether an Oracle Client is present.

    4. Senthil kumar 685 Reputation points

      Hi Aman Agrahari,

      • First copy the application in two for x32 and x64.
      • for x64 application use Oracle.ManagedDataAccess.
      • for x32 application use Oracle client 19c.
      • then try to run both application.

      this is my opinion only. its not a solution. we will find out the solution asap.

      Thanks.

    Sign in to comment

  2. AI answer

    The crash is consistent with a duplicate or conflicting DbProviderFactories / config section registration, similar to other scenarios where duplicate provider entries in machine.config or app config cause runtime failures.

    From the context:

    • .NET data providers are registered via DbProviderFactories entries in configuration files (machine.config and application .config).
    • A duplicate DbProviderFactories entry in machine.config is known to cause services to fail and must be removed to restore normal behavior.

    In this case, Oracle Client 19c likely adds its own oracle.manageddataaccess.client registration at the machine level, while the NuGet-based managed driver adds the same registration at the application level, resulting in conflicting or duplicate entries.

    To align with the documented guidance on duplicate provider entries:

    1. Check for duplicate provider entries
      • Inspect machine.config in the .NET Framework folder (for example, C:\Windows\Microsoft.Net\Framework64\v4.0.30319\Config\) and look for DbProviderFactories entries related to oracle.manageddataaccess.client.
      • If there are multiple entries for the same invariant name, remove the duplicate entry, keeping only one consistent definition.
      • Always back up machine.config before editing.
    2. Avoid redundant registrations
      • If Oracle Client 19c already registers oracle.manageddataaccess.client in machine.config, the application-level <system.data><DbProviderFactories> entry for the same invariant can be removed to avoid duplication.
      • Keep only the configuration that is necessary for the application to run. If the managed driver works without any explicit DbProviderFactories entry in .exe.config on machines without Oracle Client, then the app-level registration is not strictly required.
    3. Keep configuration consistent
      • Ensure that the section declaration for oracle.manageddataaccess.client appears only once in the effective configuration hierarchy (machine + app). Multiple declarations for the same section name with different types or versions can cause initialization failures.
      • If the Oracle Client installer has already added the section at machine level, remove the duplicate section declaration from .exe.config.
    4. Best practice for deployment
      • For a managed ODP.NET application that should run with or without Oracle Client installed, rely on a single, consistent registration of oracle.manageddataaccess.client:
        • Prefer application-local configuration (in .exe.config) when full control over the runtime environment is required, and remove conflicting machine-level entries if they cause issues.
        • Alternatively, if machine-level configuration is mandated by the environment, remove the redundant app-level entries and test the application with only the machine-level registration.
      • Before changing machine.config, create a backup and validate changes in a test environment, as incorrect edits can affect all .NET applications on the machine.

    In summary, the crash is caused by duplicate or conflicting oracle.manageddataaccess.client registrations between .exe.config and machine.config. The recommended approach is to remove the duplicate DbProviderFactories and section entries so that only one consistent registration remains, either at the machine level or at the application level, and then test the application on machines with and without Oracle Client installed.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer