Feedback

Feedback

Did this article resolve your question/issue?

   

Article

How to always use the local assembly for ADO.Net Providers

Printable View

Information

 
TitleHow to always use the local assembly for ADO.Net Providers
URL Namehow-to-always-use-the-local-assembly-for-ado-net-providers
Article Number000115690
EnvironmentProduct: Connect for ADO.Net Providers
Version: All Supported
O/S: Windows
Database: All Supported
Application: N/A
Question/Problem Description
How to always use the local assembly for ADO.Net Providers?
How to restrict an application to only use local assembly versions of the ADO.Net Providers?
Steps to Reproduce
Clarifying Information
Error Message
Defect Number
Enhancement Number
Cause
Resolution
The Microsoft .NET behavior states that the application will search the managed assemblies in this order: 

1. Global Assembly Cache 
2. The web application's bin directory or Windows application's EXE directory 
3. The x86 or x64 subdirectory based on whether the application runs in 32-bit or 64-bit .NET Framework. If the application is built using AnyCPU, then ODP.NET will use the correct DLL bitness as long as the assembly is available. Oracle recommends using this method of finding dependent assemblies if your application is AnyCPU. 

If the goal is to only use local assembly, then there should not be any assembly with same the assembly version present in the GAC. 

This situation can be handled in two ways during installation of the applications which use the Connect for ADO.Net Providers:

1. The installation process should use gacutil command if with just /i argument, so that it will GAC it only when its new. 

OR

2. The installation process should use gacutil command with /u argument. This will make sure that, the assembly is completely removed from the GAC (if present) and the .NET run-time will look for the assemblies in application’s respective working directories. 
 
Workaround
Notes
Last Modified Date9/6/2019 8:16 PM
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.


Copyright © 2022 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.

Progress, Telerik, Ipswitch, Chef, Kemp, Flowmon and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.

Terms of Use Privacy Center Security Center Trademarks License Agreements Code of Conduct Careers Offices
Do Not Sell My Personal Information