When a user logs on to DealAxis, if the local PC cannot run the Pot book grid correctly the user is redirected to the DealAxis Client Setup page. There are two main reasons why this might happen, which are that .Net permissions have not been installed or .Net code is unable to execute in the user's browser.
These redirections can lead to confusion if permissions have definitely been configured but DealAxis continues to indicate that the user's setup is incompatible. This type of issue is usually caused by installing permissions for one Internet Explorer zone but browsing to DealAxis in another zone.
The DealAxis Internet Explorer Zone page describes how to configure and be aware of the Internet Explorer zone when browsing to DealAxis. This needs to match the zone for which permissions have been configured and common reasons for this not being the case are listed below.
This type of error results in a message as follows and indicates that the user does not have the correct permissions for the DealAxis zone.
If we have established that the user is definitely in the correct zone then we next need to check that .Net permissions actually have
been installed for that zone on the user's PC.
To check whether .Net permissions have been installed, use the Security Viewer in the DealAxis Client, as described in the Checking DealAxis .Net Permissions page. If permissions are not present they can be installed as described in the Install DealAxis .Net Security Permissions page.
Common reasons for .Net permissions not being installed correctly are listed below.
If DealAxis is configured incorrectly on either the user's PC or the web server this problem can occur, which means
.Net code was unable to execute in the user's browser. This results in the following message and the DealAxis web page
is unable to execute .Net code so cannot provide further error details.
By far the most common reason for this problem is that users are browsing in the wrong Internet Explorer zone. If you are certain that this is not the case, the following sections provide further troubleshooting suggestions.
Verify that the Internet Explorer permissions in effect for the user are definitely DealAxis compliant. This can be quickly checked with the DealAxis Client tool as described in the DealAxis Internet Explorer Permissions page.
The Microsoft .Net download technology is a complex process involving comparisons of timestamps and assembly versions. We have known occasions where problems with the download process can be resolved by clearing the Temporary Internet Files cache and / or the .Net Assembly Download cache, as described in the Pot Book Assembly Downloads page.
We have known occasions where banks' proxy server scripts prevent DLLs from being allowed to download. So it is worth
checking that DLLs can be directly downloaded which can be done by clicking the below link. This should result in a
standard file download prompt as in the following screenshot. If the download prompt does not appear this indicates
that something is preventing DLLs from downloading.
Direct DLL Download
It is possible that the Execute Permissions on the web server could be configured incorrectly. In the below screenshot the
Execute Permissions are correctly set to Scripts only, and Dealogic .Net DLL files will be successfully downloaded from the web
server. If this setting is set to Scripts and executables however, then IIS will attempt to execute .Net DLLs on the web server
and the download to users' Temporary Internet Files will fail.
It is possible that HTTP compression settings on the web server could be configured incorrectly. DLL files should not be
configured to be compressed, since this prevents Internet Explorer from downloading them correctly.
This problem can be spotted when viewing Temporary Internet Files since you will see a corrupted binary with a name
of the form <Assembly Name>#<Class Name> as in the below screenshot.
This will result in a FileNotFoundException error at the Microsoft IEHost level and the DealAxis control will not be created.
The DealAxis web page will be unable to explain the error but the Microsoft Assembly Binding Log Viewer can be used to
diagnose the problem. This tool can be downloaded in ZIP format by clicking the following link.
Download the Assembly Binding Log Viewer
Run the tool, click Settings and select the Log bind failures to disk option as below. Non administrator users should
also ensure that bind information is being logged to a location to which the user has write permissions.
Next try to load the Pot book as the same user and then look at the log viewer. If the server files are mismatched there
will be output records as follows indicating failures.
Double click the log record to see its details and among the detailed output we should be able to see where the mismatch
is occurring. To resolve this type of issue the files on the server would need to be replaced with correct versions.
An alternative way to view these log details is to configure IEHost logging as described in the following Microsoft article.
Microsoft KB 313892
It can be useful to determine at what stage the .Net creation process is failing and then try to figure out why.
Copyright © Dealogic Ltd