This post was originally published here
It is not the first time, neither will be the last that I encountered similar problems like this one or the same problem with earlier versions, we call it DLL hell (or nightmare) but I think that all BizTalk Administrator are familiar with it and vaccinated for the problem. Some months ago, while trying to communicate with an Oracle database within Visual Studio in a brand-new BizTalk Server 2016 Developer environment to generate the proper Schemas, we faced with the following Oracle.DataAccess problem:
Error saving properties.
(System.ArgumentException) Invalid binding.
(System.IO.FileNotFoundException) Could not load file or assembly ‘Oracle.DataAccess, Version=4.121.1.0, Culture=neutral, PublicKeyToken=89b483f429c47342’ or one of its dependencies. The system cannot find the file specified.
Cause
When installing the Oracle WCF Adapter for BizTalk Server 2016 there is a design-time requirement to use Oracle.DataAccess Version 4.121.1.0.
BizTalk Server 2016 requires that specific Oracle.DataAccess version, however, us we were able to very on the GAC, the DLL that existed in our environment had a different version.
Trying to find the correct ODP.NET 11.2.0.1.2 version under Oracle website can be a challenge
Note: depending on the BizTalk Server version that you are using, this the required Oracle.DataAccess version may change.
Solution
Trying to find the correct ODP.NET 11.2.0.1.2 version under Oracle website can be a challenge, so one of the easier and fast ways to solve this problem is using Assembly Binding Redirection in the machine configuration file (Machine.config):
- 32-bit: c:WindowsMicrosoft.NETFramework[version]configmachine.config
- 64-bit: c:WindowsMicrosoft.NETFramework64[version]configmachine.config
Note: You should apply this in both 32 and 64-bit machine configuration files.
By using the <assemblyBinding> Element for <runtime> that will contain all the information about assembly version redirection and the locations of assemblies.
In this case, you should apply the following configurations:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Oracle.DataAccess"
publicKeyToken="89b483f429c47342" />
<bindingRedirect oldVersion="4.121.1.0" newVersion="x.xxx.x.x" />
</dependentAssembly>
</assemblyBinding>
</runtime>
By doing this when BizTalk Server will look to the Oracle.DataAccess version which not exists in your environment, it will be redirected to the existing DLL version.
For example, in our case we used:
<!--<runtime />-->
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89b483f429c47342" />
<bindingRedirect oldVersion="4.121.1.0" newVersion="4.121.2.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
Just to be on the safe side, you should add this configuration in both 32 and 64-bit in .NET Framework 2.0 and 4.0 machine configuration files.
