Application.Run generating FileNotFound exception

[Guest]

Hi,
I have an applicationthat calls Application.Run from main, and this
generates a FileNotFoundException. The solution has the main program and a
number of DLLs, and it is saying that it cannot find one of the DLLs or its
dependencies. Yet the DLL is present in the application folder, and it only
has system tool dependencies, which are also used by other DLLs that load
successfully before the one causing the problem. The DLL giving the problem
is written in C++, whereas the rest of the program is in C#, but I don't see
that causing any problems.
Any suggestions? Does .Net look elsewhere than at the files in the folder to
see if a file is present or not?
Regards,
Tim

 

[Guest]

Is it a managed C++ assembly? It sure doesn't sound like it from your
description.

Peter

 

[Willy Denoyette [MVP]]

| Hi,
| I have an applicationthat calls Application.Run from main, and this
| generates a FileNotFoundException. The solution has the main program and a
| number of DLLs, and it is saying that it cannot find one of the DLLs or
its
| dependencies. Yet the DLL is present in the application folder, and it
only
| has system tool dependencies, which are also used by other DLLs that load
| successfully before the one causing the problem. The DLL giving the
problem
| is written in C++, whereas the rest of the program is in C#, but I don't
see
| that causing any problems.
| Any suggestions? Does .Net look elsewhere than at the files in the folder
to
| see if a file is present or not?
| Regards,
| Tim

Is your DLL a native code library built with VC8? in that case you have to
embed the manifest or you have to statically link the C runtime library.

Willy.

 

[Guest]

Peter,
It is managed code, though part of it is acting as a wrapper to call other
unmanagaed DLLs. All of these unmanaged DLLs are in place.
Tim

 

[Guest]

Willy,
It is managed code developed in Visual Studio 2003. This acts as a wrapper
for some DLLs that are unmanaged code, but these are all present, and have
been used like this before with no problems.
Tim

 

[Willy Denoyette [MVP]]

There is at least a DLL missing or not found in the search path, this can be
a dependent of the wrapper dll or the native wrapped dll. Please note that
DLL's compiled with VC++ 7.1 need the VC7.1 C runtime DLL's in the path,
while the CLR (v2) uses the VC8.0 C runtime. I would suggest you to check
your dependents using dumpbin.exe or depends.exe.

Willy.

| Willy,
| It is managed code developed in Visual Studio 2003. This acts as a wrapper
| for some DLLs that are unmanaged code, but these are all present, and have
| been used like this before with no problems.
| Tim
|
| "Willy Denoyette [MVP]" wrote:
|
| >
| > | > | Hi,
| > | I have an applicationthat calls Application.Run from main, and this
| > | generates a FileNotFoundException. The solution has the main program
and a
| > | number of DLLs, and it is saying that it cannot find one of the DLLs
or
| > its
| > | dependencies. Yet the DLL is present in the application folder, and it
| > only
| > | has system tool dependencies, which are also used by other DLLs that
load
| > | successfully before the one causing the problem. The DLL giving the
| > problem
| > | is written in C++, whereas the rest of the program is in C#, but I
don't
| > see
| > | that causing any problems.
| > | Any suggestions? Does .Net look elsewhere than at the files in the
folder
| > to
| > | see if a file is present or not?
| > | Regards,
| > | Tim
| >
| > Is your DLL a native code library built with VC8? in that case you have
to
| > embed the manifest or you have to statically link the C runtime library.
| >
| > Willy.
| >
| >
| >

 

[Guest]

Willy,
Hadn't used depends before - its a useful tool , thanks for that.
Tracked it down, opengl32 and related files had disappeared from the system
somehow.
Many thanks for your help
Tim