Application File Not Valid
You may have found that connecting to your server from a client via the web after cleaning out the cache or connecting a machine for the first time results in the following error:
From the other clients you have in the system you know that the ICONICS suite is known to be working, and a clean client should simply need to download and cache the web components before launching the interface, so why does the browser now reject it?
The issue is the result of alterations to ICONICS component files and how .NET security works, so let’s go into more detail as to why this might occur and how we can resolve it.
Editing the components for client settings
In some environments, it may be necessary to alter communication timeout settings. Though this is an uncommon change to make, there are instances where the default timeout settings recommended by the .NET framework are not sufficient. This can happen on networks with high traffic where the timeout periods need to be extended or, for whatever reason, we may need to shorten the timeout for better responsiveness. In such instances, we edit a configuration file called IcoCommunication.Bindings.config.xml file that is found in the Components directory of the ICONICS product suite. There are other IcoCommunication xml files also located in this directory, but it is very unlikely that these would ever be edited as they provide protocol definition information.
Why the error?
GraphWorX64™, when used via the web, is run as a XAML Browser Application (XBAP). For more information about XBAP technology, see here. When running this XBAP, the initial download of components files will verify the necessary components on the server; this is done by a component’s location and its unique hash code which is verified against the file manifest. The aforementioned IcoCommunication files are verified in this process, but in changing the timeout settings we have changed the file’s hash code as a result. This hash code mismatch is the root of our error.
The error will only occur on clean clients because of this verification process. With the XBAP files installed on the client and the server components verified, clients will not need to reiterate this process.
In such instances we can revert the IcoCommunication.Bindings.xml file back to its original settings and doing so will restore the original hash code. Once a client has verified the files on the server, the changes can be made to the IcoCommunication file without the client rejecting it.
For a more permanent solution, you can contact our support team and we can arrange an updated XBAP to be generated for your particular application so that the manifest will match.
If you would like any more information, please Get in Touch