|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
DLL NOT FOUND (but only on certain systems???)FORTRAN .DLL. All compiled (release for VB.NET and FORTRAN), with the .EXE and the .DLL and other support files all in the same folder. On my PC it works absolutely fine. No issues whatsoever. It also works perfectly on SOME (most?) other PC's in my area. However, there are some PC's in my area where the .EXE simply refuses to find the .DLL, despite the fact that the setup is identical (single folder on the desktop that contains all necessary files). The .DLL is in the same folder as the the .EXE. The error I receive is: Unable to load DLL 'TEST.dll': This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1) Unfortunately, I am not able to debug the problem because it works perfectly for everyone when I compile the .EXE and the .DLL in debug mode. Any suggestions? I am going crazy here... Thanks...
Show quote
Hide quote
"ags5406" <my.spam.5406@gmail.com> wrote in message Is this an ActiveX dll? Is it registered correctly?news:77464592-9222-4654-ad5c-7eaad56b719c@y5g2000hsf.googlegroups.com... >I have an application written in VB.NET that calls functions in a > FORTRAN .DLL. All compiled (release for VB.NET and FORTRAN), with > the .EXE and the .DLL and other support files all in the same folder. > > On my PC it works absolutely fine. No issues whatsoever. It also > works perfectly on SOME (most?) other PC's in my area. > > However, there are some PC's in my area where the .EXE simply refuses > to find the .DLL, despite the fact that the setup is identical (single > folder on the desktop that contains all necessary files). The .DLL is > in the same folder as the the .EXE. The error I receive is: > > Unable to load DLL 'TEST.dll': This application has failed to start > because the application configuration is incorrect. Reinstalling the > application may fix this problem. (Exception from HRESULT: 0x800736B1) > > Unfortunately, I am not able to debug the problem because it works > perfectly for everyone when I compile the .EXE and the .DLL in debug > mode. > > Any suggestions? I am going crazy here... Thanks... Show quoteHide quote > >
Show quote
Hide quote
"ags5406" wrote: I seem to remember a runtime dll that we needed to distribute like f77.dll > I have an application written in VB.NET that calls functions in a > FORTRAN .DLL. All compiled (release for VB.NET and FORTRAN), with > the .EXE and the .DLL and other support files all in the same folder. > > On my PC it works absolutely fine. No issues whatsoever. It also > works perfectly on SOME (most?) other PC's in my area. > > However, there are some PC's in my area where the .EXE simply refuses > to find the .DLL, despite the fact that the setup is identical (single > folder on the desktop that contains all necessary files). The .DLL is > in the same folder as the the .EXE. The error I receive is: > > Unable to load DLL 'TEST.dll': This application has failed to start > because the application configuration is incorrect. Reinstalling the > application may fix this problem. (Exception from HRESULT: 0x800736B1) > > Unfortunately, I am not able to debug the problem because it works > perfectly for everyone when I compile the .EXE and the .DLL in debug > mode. > > Any suggestions? I am going crazy here... Thanks... > > > or f90.dll, that had to be installed into the \windows\system32 folder. Occasionally we ran into issues with permissions installing there. It's been years, and your environment may be quite different than we had at the time. Isn't there some runtime library such as f77.dll or f90.dll that you need to distribute with the Not ActiveX.
There are Fortran runtime DLL's, and they are included in the distribution. There is definitely something very screwy going on. Last night I updated the .TEXT of a label on one single form by adding ONE, just ONE extra character. For example, the lblTest.Text = "ABC" was changed to lblTest.Text = "ABCD". Literally the only change I made to the code. Recompiled and reran and then magically, all of a sudden, all of my problems have disappeared. The package seems to work correctly on all PC's in my area now. One thing I did notice is that my executable increased in size from 1408 KB to 1552 KB. How or why adding one single character to the code (which is hundreds of thousands of lines in total) could increase the executable size by 10% is beyond me. And why adding one single character to the code would fix a seemingly unrelated problem is also beyond me. Methinks I have a gremlin. I have always believed that "the program only does what you tell it to do", but this is the first time I'm starting to doubt that. All of my projects are under source control (we use CVS), so I am able to ensure which version I am using. I am able to REPEAT the problem with the first executable and I am able to REPEAT the success with the second executable (with the one extra character in the code).
Disecting Strings
Removing reference type members from a generic list clone Fastest way to import large fixed width file into a DataTable OT - Vista Search and Recursive GetFiles XML Deserializer problem Is setting Bounds Property the same as setting Size and Location? Multithreading Invoke Workaround Convert code line to VB Bug in VWD 2008 Express? References to different versions of MS Outlook in a VB.NET application |
|||||||||||||||||||||||