Identifying the .NET assembly at run time

The rules that govern how the .NET assembly is loaded from the integration node file system if it is not packaged in the BAR file.

About this task

The .NET configuration for an integration server is controlled by properties on the .NET node or the ESQL Procedure signature. Optionally, a DotNet Application Domain policy can also be defined for further configuration options. A message flow can invoke assemblies that run within an integration server that uses the Microsoft Common Language Runtime (CLR). Flow developers can control the .NET framework assemblies that are loaded, and the .NET application domains which are used. Assemblies are invoked either from a .NET node in a message flow, or by calling an ESQL procedure.

Application domains

About this task

The .NET framework separates application assemblies to run in a particular application domain that provides a scope for the resources for an application. In IBM® App Connect Enterprise, the integration server operating system process (DataFlowEngine) hosts the CLR. Within this process, .NET assemblies can be executed within multiple application domains if required.
  • The AppDomain name property of a .NET node specifies the application domain in which the assembly is to be loaded. If a DotNet Application Domain policy is defined with the same name as the AppDomain name property of the node, the policy properties take precedence when the assembly is loaded. Such properties include the Application Base directory property.
  • When an ESQL procedure invokes a .NET assembly, the signature of the procedure can specify the application domain in which the assembly must be loaded. If a DotNet Application Domain policy is defined with the name that is specified for the application domain in the signature of the ESQL procedure, the policy properties (for example the Application Base directory) take precedence when the assembly is loaded.
If no application domain is specified by the preceding methods, the application domain in which the assembly is loaded is determined by:
  • The name of the application, if deployed within an IBM App Connect Enterprise application
  • The name of the integration server, if deployed in a flow which is not defined within an IBM App Connect Enterprise application

If the application domain is determined by the name of the application or the name of the integration server, and a DotNet Application Domain policy is defined with the same name, the policy properties (for example, the Application Base directory) take precedence when the assembly is loaded. If the application name or integration server name includes space characters, these characters are ignored when the application name or integration server name is compared to the name of the policy.

Application base directory

About this task

To understand which copy of an assembly will be loaded, first determine the Application Base directory.
  1. If the Application domain property refers to a policy, the Application base property of the policy is used. Use this approach in production environments.
    Note: The policy properties, including Application base, always take precedence even if you have deployed a .NET application domain that contains the assemblies to the run time. In this situation, to ensure that the .NET assembly is loaded from the .appdomainzip and not from the Application Base directory, ensure that the Application base property of the policy is blank.
  2. If the Assembly name property of the .NET node (or equivalent part of the ESQL procedure signature) specifies an absolute location in the file system, this full directory path is used as the Application Base directory.
  3. If the Assembly name property of the .NET node (or equivalent part of the ESQL procedure signature) specifies just the name of the .dll file with no path, the integration node uses a subdirectory of the runtime integration node's work path for the Application Base directory. This directory might change; consider using one of the alternative approaches.

Assembly loading and the Global Assembly Cache

About this task

The integration node expects to find the required .NET assembly in the Application Base directory. However, you can place assemblies in a machine-wide cache, which is known as the Global Assembly Cache (GAC). To place an assembly into the GAC, it must be Strong-Named: when it is compiled, the assembly is given the properties of a version, a culture, and a public key token. When configuring the .NET node or an invocation from ESQL, you can specify the version, culture, and public key token of the Strong-Named assembly to be used.

You have to restart the integration server if you want to reload or update a Strong-Named assembly.