Integrating .NET V2.0 Framework with GridServer V4.2
Article ID: KB0090836
Updated On:
| Products | Versions |
|---|---|
| TIBCO DataSynapse GridServer | - |
| Not Applicable | - |
Description
Resolution:
In order for a .NET V2.0 Service and Client application to interoperate smoothly with GridServer 4.2, changes are necessary on both the Engine and Client side. These changes are necessary due to changes in default behaviour that Microsoft has introduced between .NET V1.1 and .NET V2.0.
On the Engine side, GridServer 4.2 takes advantage of certain behaviours in the Fusion Assembly loader that have changed between .NET V1.1, and .NET V2.0, which means that with the default configuration, .NET V2.0 Services will fail to run on the Grid. Microsoft has, however, provided a configuration option to enable the .NET V2.0 Fusion Assembly loader to operate in a backward-compatible mode, which allows a .NET V2.0 Service to run successfully with GridServer 4.2.
To enable this backward-compatible mode, the invoke.exe.config configuration file in the livecluster/engineUpdate/win32 directory on the Primary Director should be updated to merge in the following XML:
<configuration>
<runtime>
<disableCachingBindingFailures enabled="1" />
</runtime>
</configuration>
For example, assuming a default installation of GridServer 4.2, with Update 6 or later applied and no prior customization of invoke.exe.config, then the content of this file becomes:
<?xml version="1.0"?>
<configuration>
<runtime>
<disableCachingBindingFailures enabled="1" />
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="GridServerNETClient" publicKeyToken="42129437978483df" />
<bindingRedirect oldVersion="4.0.0.0-4.2.0.27" newVersion="4.2.0.28" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Note that due to the checks made by the Engine to determine if a .NET Framework is available on a particular Engine node, both the .NET V1.1 and .NET V2.0 Frameworks must be installed. If .NET V1.1 is not present, the Engine will become discriminated against, and will not be assigned any .NET Service tasks. Note that with GridServer 4.2 the version of the .NET Framework that is loaded on an Engine at the time it takes a task cannot be accurately determined - if the Framework is not currently loaded, the Engine will load the Framework version requested by the assembly implementing the Service or the highest-numbered Framework version if the assembly does not specify one. If a version of the Framework is already loaded, that version will be used to execute the Service. For this reason, if it is necessary to force the Engine to use a particular version of the .NET Framework, the following XML should be added to the element above:
To force the use of .NET Framework 1.1
<startup>
<supportedRuntime version="v1.1.4322"/>
</startup>
To force the use of .NET Framework 2.0
<startup>
<supportedRuntime version="v2.0.50727"/>
</startup>
On the Client side, a further change is required if .NET V2.0 clients are to be used. This change is required because Microsoft have changed the default behaviour in .NET V2.0 such that if an HTTP proxy is defined for Internet Explorer, then it will also be used by the .NET Framework. This was not the case for .NET V1.1.
The symptom of this would be that a .NET V2.0 Client application could (if making short-lived requests to the Grid) appear to perform extremely poorly as compared to a .NET V1.1 or Java equivalent.
To workaround this change in behaviour, the Client's .NET configuration file should be edited (or created) to merge in the following XML:
<configuration>
<system.net>
<defaultProxy>
<proxy bypassonlocal="true" usesystemdefault="false" />
</defaultProxy>
</system.net>
</configuration>
Note that the configuration filename depends on the application - for example, if the CalculatorClient sample application is used, which creates the CalculatorClient.exe executable, then the configuration file would be CalculatorClient.exe.config.
In order for a .NET V2.0 Service and Client application to interoperate smoothly with GridServer 4.2, changes are necessary on both the Engine and Client side. These changes are necessary due to changes in default behaviour that Microsoft has introduced between .NET V1.1 and .NET V2.0.
On the Engine side, GridServer 4.2 takes advantage of certain behaviours in the Fusion Assembly loader that have changed between .NET V1.1, and .NET V2.0, which means that with the default configuration, .NET V2.0 Services will fail to run on the Grid. Microsoft has, however, provided a configuration option to enable the .NET V2.0 Fusion Assembly loader to operate in a backward-compatible mode, which allows a .NET V2.0 Service to run successfully with GridServer 4.2.
To enable this backward-compatible mode, the invoke.exe.config configuration file in the livecluster/engineUpdate/win32 directory on the Primary Director should be updated to merge in the following XML:
<configuration>
<runtime>
<disableCachingBindingFailures enabled="1" />
</runtime>
</configuration>
For example, assuming a default installation of GridServer 4.2, with Update 6 or later applied and no prior customization of invoke.exe.config, then the content of this file becomes:
<?xml version="1.0"?>
<configuration>
<runtime>
<disableCachingBindingFailures enabled="1" />
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="GridServerNETClient" publicKeyToken="42129437978483df" />
<bindingRedirect oldVersion="4.0.0.0-4.2.0.27" newVersion="4.2.0.28" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Note that due to the checks made by the Engine to determine if a .NET Framework is available on a particular Engine node, both the .NET V1.1 and .NET V2.0 Frameworks must be installed. If .NET V1.1 is not present, the Engine will become discriminated against, and will not be assigned any .NET Service tasks. Note that with GridServer 4.2 the version of the .NET Framework that is loaded on an Engine at the time it takes a task cannot be accurately determined - if the Framework is not currently loaded, the Engine will load the Framework version requested by the assembly implementing the Service or the highest-numbered Framework version if the assembly does not specify one. If a version of the Framework is already loaded, that version will be used to execute the Service. For this reason, if it is necessary to force the Engine to use a particular version of the .NET Framework, the following XML should be added to the element above:
To force the use of .NET Framework 1.1
<startup>
<supportedRuntime version="v1.1.4322"/>
</startup>
To force the use of .NET Framework 2.0
<startup>
<supportedRuntime version="v2.0.50727"/>
</startup>
On the Client side, a further change is required if .NET V2.0 clients are to be used. This change is required because Microsoft have changed the default behaviour in .NET V2.0 such that if an HTTP proxy is defined for Internet Explorer, then it will also be used by the .NET Framework. This was not the case for .NET V1.1.
The symptom of this would be that a .NET V2.0 Client application could (if making short-lived requests to the Grid) appear to perform extremely poorly as compared to a .NET V1.1 or Java equivalent.
To workaround this change in behaviour, the Client's .NET configuration file should be edited (or created) to merge in the following XML:
<configuration>
<system.net>
<defaultProxy>
<proxy bypassonlocal="true" usesystemdefault="false" />
</defaultProxy>
</system.net>
</configuration>
Note that the configuration filename depends on the application - for example, if the CalculatorClient sample application is used, which creates the CalculatorClient.exe executable, then the configuration file would be CalculatorClient.exe.config.
Issue/Introduction
Integrating .NET V2.0 Framework with GridServer V4.2
Feedback
Yes
No
Powered by
