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 node is controlled by properties on the .NET node or the ESQL Procedure signature. Optionally a DotNetAppDomain configurable service can also be defined for further configuration options. A message flow can invoke assemblies that run within the integration server of an integration node using 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® Integration Bus, 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 DotNetAppDomain configurable service is defined with the same name as the AppDomain name of the node, the configurable service 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 DotNetAppDomain configurable service is defined with the name which is specified for the application domain in the signature of the ESQL procedure, the configurable service 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 Integration Bus application
  • The name of the integration server, if deployed in a flow which is not defined within an IBM Integration Bus application
If the application domain is determined by the name of the application or the name of the integration server, and a DotNetAppDomain configurable service is defined with the same name, the configurable service 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 configurable service.

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 configurable service, the ApplicationBase property of the configurable service is used. Use this approach in production environments.
    Note: The configurable service properties, including ApplicationBase, always take precedence even if you have deployed a .NET application domain containing 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 configurable service ApplicationBase property 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.