Skip to main content

We have a product deployed at the site of multiple customers and that application is using IFS 9/10 and the .NET Access Provider to connect to IFS. We have 2 customers that are still using IFS 9 and both have connection problems to IFS 9 since last night. There was no change to our product and both customers use different versions of our product anyway.

Is there any changes done to IFS 9 like an update or an end-of-support date that happened recently?

The error is (URL/username were edited):
Cannot connect to IFS using URL 'http://ifsurl:60000/' and username 'IFSUSER'.
Unexpected error while calling server method AccessPlsql/Invoke
The URI http://ifsurl:60000/main/compatibility/clientgateway cannot be found. Please contact your system administrator.

The access to IFS 9 itself - using Entreprise Explorer and the same login information - is correct in both sites.

Hi @MicLabElmo 

It’s a long shot, but could it be that your product is using .NET access provider dlls for Apps10 to access Apps9 version of the product?

 

/Damith

Hi @dsj ,

You are right that it happened many times - when reinstalling our product on the sites of these two clients - that the IFS 10 DLLs were used instead (the DLLs of IFS 10 are installed by default by our product). I forgot to mention that this time we checked and it is not the case: the DLLs for IFS 9 (File version = 9.0.16.0) are in place in the directory where our product loads its DLLs.

My guess as Apps9 is out of support now for quite a while and has not done any updates for a long time, is that a Windows update has updated the .Net runtime libraries. Here? C:\Windows\Microsoft.NET\Framework

What you need to do is to try to force the old Aps9 access provider to use equally old .Net frameworks… 

Also tell the customer it is dangerous to run unsupported products… :) 

I found the reason why we had this behavior by doing more tests with one of the customer. The .NET Access Provider DLLs our product was using for IFS 9 were outdated. The version used was 9.0.16.0. I asked one customer to copy the DLLs from his IFS server into the directory of our product and it solved the problem. The copied DLLs were at version 9.0.41.0. I planned to update the DLLs used within our product for the next setups/hotfixes. I do not know why it broke suddently - the same day at both sites - but we now have a working solution.

I will select the answer of @dsj as the best one since it is the nearest of the solution found (problem with the version of the DLLs used). Thank you everybody for the help.

I found the reason why we had this behavior by doing more tests with one of the customer. The .NET Access Provider DLLs our product was using for IFS 9 were outdated. The version used was 9.0.16.0. I asked one customer to copy the DLLs from his IFS server into the directory of our product and it solved the problem. The copied DLLs were at version 9.0.41.0. I planned to update the DLLs used within our product for the next setups/hotfixes. I do not know why it broke suddently - the same day at both sites - but we now have a working solution.

I will select the answer of @dsj as the best one since it is the nearest of the solution found (problem with the version of the DLLs used). Thank you everybody for the help.

 

Glad to hear it’s working :)

If you’d like to know what has been changed between  binary patch level 9.0.16.0 and 9.0.41.0, it can be found here: IFS Apps 9 - Enterprise Explorer Client Framework Binary Patch Change Log | IFS Community

 

Cheers!

Damith

Reply


Terms & ConditionsCookie settings