Exception error when trying to run an application on non-development machine

[Debbie]

Hi

I have developed an application that access an SQL database and installed it on a different machine

The installation is successful but when I try to run the application I get the following error

Application has generated an exception that could not be handled

Process id = 0x610 (1552), Thread id=0x1d0(464)

Click OK to terminate the applicatio
Click CANCEL to debug the application

As the installation machine does not have visual studio.net installed on it I cannot debug the application so am only able to click on OK to terminate the application. I can successfully install and run the application on the development machine (outside the visual studio.net environment) so can't replicate this error. Previously the application installed and opened correctly on the non-development machine (although I am expecting an error when trying to actually update the SQL database with the application).

I cannot see any changes in the code between the successful installation and opening of the application and the subsequent failures. Is there anyway that I can force this error to occur on the development machine or is there any idea where I can put some MessageBox displays to help find where this error occurs on the non-development machine? I have a MessageBox just after the InitialiseCompenent function call at the start of the application and it gets past this but then stops with this error.

Sorry to be so long winded but I am new to dotnet. programming and would appreciate any help

Thanks

debbie

[bdivine]

We have a programmer at our company that is experiencing the same exact problem. What we have found is that their is a missing dll or ocx that you are not including in your deployment package. We used to use a tool called a dependency walker that allows you to find what components are missing. Perhaps you might want to try a shot gun approach. Include more than you know is necessary to perhaps include the missing component. Also you can do DLL compare against your machine and the client machine. This would at least give you a place to start. If you find what is missing please let us know. We are in the same stage of research as it sounds that you are.

One of our most previlent errors is on trusting assemblies, ie full trust in the .Net framework intranet settings. But this one does not seem to point to that type of issue.

************************************************** ********************
Sent via Fuzzy Software @ http://www.fuzzysoftware.com/
Comprehensive, categorised, searchable collection of links to ASP & ASP.NET resources...

[response]

Hi Debbie
I came across your problem description when I was searching for help on the same problem. Selfishly, I am hoping you have found a solution so you can pass it on to me.
In my case, the problem occurs in an application that has aleady sold to thousands of happy users. Only a handful of users get the problem when they try to fire up the app. Our app doesn't use SQL Server. The only external processer it does access is Internet Explorer as an ActiveX control. Our difficulty is that we cannot persuade any of the affected users to help us to isolate the fault, so debugging is an impossibility. Somewhere in the bowels of the .NET framework the app is prevented from usind a dll, either because it is not there, or the permissions are wrong. This must be connected with the particular configuration that the affected users have. It is not peculiar to any one operating system. That's about all I know, but it might help. Terence

************************************************** ********************
Sent via Fuzzy Software @ http://www.fuzzysoftware.com/
Comprehensive, categorised, searchable collection of links to ASP & ASP.NET resources...