I have a custom component built in Visual Studio 2010 that is running on Desktop Basic 10.1. It is programmed in VB.net targeting 3.5 framework. The .msi installer works fine. The first part of the program runs OK on all machines (entry screens and data verification). The code then does a long series of intersects, appends, file creation, calculations and writes to the newly created tables in personal geodatabases. These steps work fine on all machines.
The code now calls a console application that tries to use the created data files in an iterative simulation. It runs fine on my PC. On all of the client's machines, it throws a bewildering array of errors I never seen during debugging. They are different on different machines occurring at slightly different points in the code execution. They all seem to have something to do with memory errors. I get subscript out of range, no instance of object, null parameters passed, invalid data type used as parameter, etc etc etc. These would all be blatant coding errors I would have seen in the debugging process.
I installed Visual Studio on a client machine and stepped through the debugger - It worked fine!
How can this be? What is the use of a debugger that doesn't emulate the end code execution? Why does the release version not crash on my PC? The operating systems are the same, the software is the same, the data is the same, the license is being recognized properly.
If I am targeting .NET 3.5 in the compiler options, should I specifically list all of the 3.5 assemblies in the references on the advanced compiler tab? Is it possible that some PCs may have different versions of that underlying code?
Can anyone point me in some direction please? What should I be looking for to fix this?
Without actually seeing a sample of the error message I'm just thinking out aloud here.
Have you tried setting the target CPU to x86 under the Project properties > compile > advanced compiler settings?
At what point do the errors occur, before the console program starts or some random point during it?
It sounds like something is being installed on your machine which is not being packaged up by your installer or is simply missing from your clients machines? Is it some horrible citrix setup and the libraries are not being installed on the clients machine?
Have you checked everything is actually being packaged up by the installer?
Thanks for taking the time to help. I did not copy down all of the exact error messages on 7 different machines for many many attempts - they were all of a similar theme so I have to start with a general area of fixes. You have provided some possibilities.
The errors occur at different points within the program. The console launches and processing begins normally. The crash happens at slightly different progressions on each machine.
It is compiled to x86 for all assemblies.
Could this be a memory leak? I have 16gb. They have 8 or less. Could it be that they hit problems before I do because I have more ram and make it through the run before a problem occurs?
The original programmer has placed many garbage collection calls and in places uses a System.Threading.Thread.Sleep(5000) before calling for garbage collection. I am thinking he has tried a workaround to the same problem I have now encountered????
My first thought was that my msi did not provide something to the new installs that is present on my machine. How do I determine?
The machines that failed to work were all laptops connected to a desktop over a network. The data and application were physically located on the desktop. We checked out a Arc license and installed locally on one laptop with the same result. I think this rules out a network problem?
If I target .net 3.5, do I have to list all of the 3.5 assemblies in the references on the compiler settings windows?