Assemblies.config files: Difference between revisions
| Line 7: | Line 7: | ||
= The problem = | = The problem = | ||
In some cases, the full closure of assembly binding redirections cannot be determined by the mechanism described above. There are various scenarios in which this can happen, but they generally fall into two categories: | |||
* You are using a development tool that does not support generating the assembly binding redirections. | |||
* Situations in which the full set of referenced NuGet packages/assemblies is not known upfront (such as dynamic loading). | |||
Consider, for example, a set of COM components (which can be QuickOPC) developed in .NET Framework and dependent on various NuGet packages. These components reside in .NET assemblies which are registered for COM interop. When a COM application creates and uses a COM object from one of these assemblies, the code in the COM component needs to load the dependent assemblies, and at that moment the assembly binding redirections must be correctly in place. But, because the top-level application (executable) is not something that was actually built with the NuGet packages (it only references the COM components), the top-level application will not have the proper binding redirections in its configuration file, and there will eventually be an assembly loading failure. | |||
= The solution = | = The solution = | ||
Revision as of 17:42, 29 May 2022
This article describes the role of the assemblies.config file in QuickOPC.
Note: The mechanism described here applies to QuickOPC 2022.2 or later.
Background
When NuGet packages are referenced in .NET Framework, and their dependency packages are pulled in (recursively), it is often the case that different packages end up referencing different versions of the same assembly. Since only a single version of an assembly can be loaded, assembly version redirection (binding redirection) is used to redirect references to different versions of an assembly to a single compatible version. Assembly binding redirections can be specified in .NET Framework configuration files, per-application or machine-wide. In order for this mechanism to function properly, a full set of NuGet packages used by the application must be known. When building an application, common build tools (such as Visual Studio) provide a way to automatically determine the "closure" of the assembly binding redirections needed for the application, and are capable of generating the application configuration file with all necessary assembly binding redirections for you.
The problem
In some cases, the full closure of assembly binding redirections cannot be determined by the mechanism described above. There are various scenarios in which this can happen, but they generally fall into two categories:
- You are using a development tool that does not support generating the assembly binding redirections.
- Situations in which the full set of referenced NuGet packages/assemblies is not known upfront (such as dynamic loading).
Consider, for example, a set of COM components (which can be QuickOPC) developed in .NET Framework and dependent on various NuGet packages. These components reside in .NET assemblies which are registered for COM interop. When a COM application creates and uses a COM object from one of these assemblies, the code in the COM component needs to load the dependent assemblies, and at that moment the assembly binding redirections must be correctly in place. But, because the top-level application (executable) is not something that was actually built with the NuGet packages (it only references the COM components), the top-level application will not have the proper binding redirections in its configuration file, and there will eventually be an assembly loading failure.
The solution
More
Related reading:
