Proparse on Windows Server 2012 gives intermittent System.IO

Posted by Mark Davies on 04-Sep-2015 04:45


Our development server was recently updated from Windows server 2003 to Windows Server 2012 and since then we have seen intermittent errors while using ProLint.

We have a number of developers that run our development environment (OE10.2B - AppBuilder / RTB with DWP) on this Windows Server 2012 terminal server and since the upgrade we have found that - sometimes - as soon as they run ProLint manually or during a task check-in through RTB that they will get the following error:

System.IO.FileNotFoundException: Could not load file or assembly '', Version=, Culture=neutral, PublicKeyToken=cda1b098b1034b24' or one of its dependencies. The system cannot find the file specified.

The strange thing here is that it doesn't happen all the time - sometimes they would log into a fresh session and ProLint runs just fine. I then thought it might be that the 2012 server is locking the dll if another user is busy with ProLint and we tested this theory by having two users running ProLint at the same time, unfortunately that worked just fine for that instance - seems very random at this stage and I am not sure if we are missing something blatantly obvious here... Anyone else experienced this problem before?

The setup of the environment is pretty simple, I have the Start In folder of the desktop icon set to the location of ProLint and the folder specified here is also the folder where the .dll is located. I also checked that when we see the error that the current project path is still the same and that also checked out.

I am a bit stumped here and the developers are loosing faith in ProLint - I really do not want to turn it off. Any advice would be greatly appreciated.

All Replies

Posted by Garry Hall on 04-Sep-2015 08:35

I have had mixed success debugging these sorts of errors with the Fusion Log Viewer (fuslogvw.exe). It should give you some information as to why the bind failed. I've also tried SysInternals ProcMon to see what files the process was trying to load, and from where, but .NET provides some abstraction here, so that you don't really know why something "failed".

It might be useful for you to know what dependencies has, so you know which assemblies to monitor. You can get this through .NET reflection in the ABL, using Assembly.LoadFrom() and GetReferencedAssemblies().

This thread is closed