CSE ERROR:VERSION CHECK:

[jbrobston]

After Windows 10 and Visual Studio 2017 installed several updates, I'm getting an error message any time I try to access CSE.

Code: Select all

     ⎕cself←'C'⎕cse 'Init' 'System'
CSE ERROR: VERSION CHECK: Object reference not set to an instance of an object.-   at APLNext.TestForAPLWin.APLTester.CheckForAPLWinFileVer(Int32 majorPart, Int32 minorPa
      rt, Int32 buildPart, Int32 privatePart)

   at APLNext.CSScriptEngine.ScriptHost2.InitializeScriptEngine(String[] references)
      ⎕cself←'C'⎕cse 'Init' 'System'
                 ^

(note that on screen the caret is directly under the quad in quad-cse).

.net is showing Release 46184 and Version 4.7.03190

Any ideas?

[jbrobston]

Forgot to mention, APL version 16.2.

[Ajay Askoolum]

I have Visual Studio 17 version 15.9.11 with Net Framework version 4.7.03190 on a Windows 10 laptop. I am unable to reproduce your error with APL+Win version 18.0.

I think []CSE has a dependency on Net Framework 4.6: do you have this installed? APL+Win version 16.2 may have a dependency on an even earlier version of Net Framework - no doubt Technical Support will clarify.

[Tech Support]

We received an identical error report last year from another customer with APL+Win 18.1 and CSE 3.0.24.0. The problem was that their Windows 10 machine had 4.6.x and 4.7.x releases of the Microsoft .NET Framework that included the string "General Release" (as reported by ASoft's .NET Version Detector) that appears to be unsupported in the CSE. So check your Microsoft .NET Framework version. And if it also contains the same string "General Release", do as the previous customer did to solve the problem and apply a newer Windows Update that included the 4.6.x and 4.7.x releases of the Microsoft .NET Framework that included the name "Windows 10 April 2018 Update".

[jbrobston]

Thank you. A little more investigation reveals that one one machine here where CSE seems to be behaving normally there are in C:\Windows\Microsoft.NET\Framework\v4.0.30319 7 files clr.dll, clrjit.dll mscordacwks.dll, mscordbi.dll, mscorlib.dll, peverify.dll, and SOS.dll dated 1/4/2019 and showing version 4.7.3362.0. On the machine that is misbehaving the same files are dated 1/31/2019 with version 4.7.3394.0. Tomorrow I will try to prevail on the Powers That Be to roll these files back and see if that corrects the problem.

[Tech Support]

I'm curious to learn what is the version information reported in ASoft's .NET Version Detector on the machine with the problem?

[jbrobston]

I don't know how useful this is, but . . .

Running the ASOFT program on the machine with the problem is going to require going through the whole Fortune 100 Information Risk Management approval process, which is to say it's not going to happen any time soon.

I checked my home machine (on which I do not have an APL+Win version newer than 2.0 alas) and found that it has the the dotnet 4.7.03190 with the 3662 CLR (this matches the machine that is _working_). That shows on the ASOFT tool as "4.7.2 General Release".

On Monday I will see if I can put together a list of updates and applications that are on my work machine and try to install those one by one on my home machine to see if I can find one that makes the same change to the clr, and then if successful run the ASOFT program against it.

[Tech Support]

John: Have you made any further progress on this?

[Tech Support]

We are happy to report that a possible fix for this issue is now available. Please refer to C# Script Engine (CSE) v3.0.25.0 Update for APL+Win v17+ for the details.