views:

23

answers:

1

Hello guys,

To start off, I'd like to say I'm rather unfamiliar with the Windows linking system. (Most of my programming experience was acquired on Mac OS, on which linking libraries and framework is radically different. I'm also not much of a Windows user.)

This is my setup: I've got two projects in the same solution. The first is a C++/CLI project we'll call Foo. Foo is a library project that depends on an external library (the Java Runtime Environment), and thus has the appropriate reference to the appropriate (I believe since it compiles) .lib file. (I changed no other project setting related to loading that library.) My other project, Bar is a C# console executable project that references Foo.

Both compile just fine.

However, when I execute my Bar.exe C# program, it dies before the construction of the first object that requires types from Foo. The exception is a FileNotFoundException that states the Foo.dll assembly or one of its dependencies couldn't be found.

So I launched fuslogvw to see what went wrong, but I don't really understand how it works, and the documentation I found on it is rather unhelpful. From what I think I understand, both Foo and Bar failed to load as native images, but were found to be correct IL and were properly loaded that way. There is no other relevant mention of failure, though, obviously it does fail at some point. I'd post the logs, but they're in French and I think it would be pretty useless.

Any idea?

+1  A: 

Are all the executable and dll dependencies in the output directory? Check the native dependencies first with Depends.

Sean Fausett
The external library's DLL is not in the output directory, and Depends indeed reports it couldn't find it. Do I need to copy the DLL there, or is there a more elegant solution? Deployment of this project will most likely happen only on machines on which I'll have full control.
zneak
That would depend on exactly how you're linking to the DLL and therefore how it's being loaded, which will likely involve DLL search order. See http://msdn.microsoft.com/en-us/library/ms682586.aspx for details.
Sean Fausett
So I would copy the DLL to the output directory first, to make sure it solves the current problem, then decide what to do about deployment.
Sean Fausett
Yeah, I stumbled on that page earlier. My problem is that this DLL depends on more libraries that are loaded at runtime, so it seems I can't copy it away. For now I've added its path in `PATH`.
zneak
I was wondering about that since you mentioned the JRE. I'm curious now... does adding to PATH solve it?
Sean Fausett
Yes, even adding it from Bar.exe through `Environment.SetEnvironmentVariable` before the DLL loads works. Though, I've added both the directory where `jvm.dll` is and where the rest of the libraries are; I'm not sure if the path for the rest is necessary, but it gets the work done so I'll leave it as is.
zneak