Debug mode, "unable to load game library", visual studio hints?

#1 Delete all binaries, clean and rebuild?

#2 Lol, you're probably right, I actually haven't gotten around to that yet. :-P

#3 Huh, well actually nope, that didn't do it either. Hmmm. I've seen this pop up various times over the years, and found a couple of inconclusive episodes on the forums, but I'm not sure if it has anything to do with Torque or is just a generic VS misconfiguration. I'm pretty weak on where all the paths and global variables etc. actually get defined in VS, and my current setup somehow ended up with all my obj files getting dumped into directories right in my game directory. :-P

But even with all that, I used to be able to run debug mode! Will let you know if I figure it out.

#4 Sounds like to me you have incorrect debugging working directory setup in the executable project. It needs to be set to $(TargetDir).

Also if you have updated Engine/source/main/main.cpp from T3D development branch and created the project much earlier than a month ago then that's the problem since the naming convention of the DLL project has been changed to fix the executable and DLL project .lib naming conflict which also resolved the annoying complete relinking each build time.

#5 That shouldn't cause problems finding the DLL, because there's a clause there that searches for the old name as well as the new one. But yeah, try regenerating your solutions just in case. I intended the code to work in situations like this, but if it doesn't then we'll either fix the code in main.cpp or make it only look for the new name, which would simplify it.

The PR for reference.

#6 Ah, this sounds close to the mark. Yes, my project is from *much* earlier than a month ago, lol. Unfortunately regenerating the solutions might require quite a bit of reassembly on my end, given all the stuff I've added, but this definitely gives me something to work with.

#7 Hm, wow, well this has been interesting... a very good opportunity to catch up on a lot of VS configuration stuff that I've never really understood. (Still attempting to beat my existing project/solution files into submission rather than start all over and add everything back into new ones.)

What I accomplished so far:
1) changed the dll target names (for debug and release) by going to my DLL project properties, Configuration Properties -> General -> Target Name. Set to "Ecstasy Motion_DEBUG DLL" or "Ecstasy Motion DLL"

2) Double checked my Configuration Properties -> Linker -> General -> Output File, because I had gotten that hard coded to my project name at some point, returned it to the proper "$(OutDir)$(TargetName).dll" format.

3) Here's where it started getting interesting for me - went into my main exe project properties, to Common Properties -> Framework & References, and removed the old reference to the dll, and added a new one, after building the dll. Don't know how I made it for this many years as a (lazy) programmer without ever quite grokking this bit, but for anyone else as ignorant as me, this seems to be how you manually tell a project to load another project as a library/dll in VS. Add a new reference under Framework & References. There ya go. :-P

Anyway, doing this results in a correctly named dll being created, and upon execution the correctly named dll gets loaded, even _with_ debug information (although it still is not finding that for the main executable - in practical terms that wouldn't much matter but it might still signify a configuration problem.)

But despite all this, when I try to run in debug mode from VS, I _still_ get the message "Unable to load game library" with a path to the _OLD_ dll name. :-P Still seeking where it's telling itself to do that.

#8 I've been making a bad habit of directly manipulating the .vsproj files - mostly to correct intermediate file output paths - with Notepad++. Perhaps open those project files up and search for the old dll name.

#9 Ooh, that does sound delightfully naughty. :-) In the middle of a full rebuild, but when it gets done I'll certainly try that!

#10 Oh for ****'s sake... the whole point of that rename was to avoid collision with the .lib file, right? Well now my project is producing the above dll plus a lib named "Ecstasy Motion_DEBUG DLL.lib".

Can anyone give me a quick remedial course in how the lib and the dll actually fit together, anyway? Is the lib a separate thing on its own or is it merely an intermediate step toward forming the dll?

Ah, the build environment, my *favorite* part of coding... :-P

#11 That shouldn't matter - dll is Dynamic Link Library, while the lib is for static linking. They should be able to co-exist with no problems; either you're linking statically or dynamically....

#12 Huh, well still dynamic linking so that shouldn't be an issue. Couldn't find anything using my bad old dll name in the project files either. Currently rebuilding another stock Empty template build to compare against. Very weird.

#13 Hmmm, OMFGWTF. This is interesting. I'm reviving this thread to share some more information on it... The way I got into this problem was merging all of the new changes from T3D into my two year old project, which itself had been upgraded from VS 2008 to 2010 in the past, so I figured the only sure way out of the problem was to go the other way and merge all of my changes into a clean, functioning T3D build.

Well, guess what? Yup, same exact behavior. It would be nice to be able to make all my changes incrementally, but there were so many interlocking parts that I just went for it all at once, and here I am.

What is interesting and new, though, is I just figured out that my problem is not actually that it is trying the wrong DLL name. I got into main.cpp where it is spawning this message, and it is actually trying both versions of the name there, first the right one (Ecstasy Motion_DEBUG DLL.dll) and then the wrong one (Ecstasy Motion_DEBUG.dll), but on failure it reports only the last (wrong) one.

So my problem is actually finding out why the WINAPI LoadLibraryW() function cannot load my dll, even though it is sitting right there, and the release version works fine, at least enough to come up with a splash screen before crashing.

So anyway, just sharing my pain, not expecting anyone to know how to resolve this particular sticky wicket, but by all means, if anybody has any ideas I'm all ears!

EDIT: Oh, and just to be clear, it is *not* just a problem of running debug mode in Visual Studio - clicking on the debug .exe does exactly the same thing.

#14 Ok, I don't really have any idea here except to perhaps delete the intermediate file folders (<t3d folder>/my projects/<project>/buildFiles/Link) entirely and rebuild again. It might be some weirdness in the generation of the dll that for some reason isn't being caught, I suppose.

Sorry, that's all I've got... this is really weird.

#15 Heh, no problem, not expecting any miracles! Out of the house right now but doing a full rebuild, if that doesn't work I'll try what you suggest. Otherwise I guess it's back to revert and merging bit by bit, argh. :-p

#16 Oh yeah, manual, file-by-file merge! All teh funz!

#17 AHHH! GOT IT. Whew.

Turned out in the output it became obvious that my main dll actually was being loaded, debug info and all, but it was failing in the process of loading the rest of the supporting DLLs. To be exact, fbxsdk, debug version. When I stopped trying to use their debug version and went back to the same one the release build uses, the problem went away.

Could be related to the fact that I'm still using my vs2008 version fbxsdk after moving the project up to vs2010. :-P

WHEW! Wasn't much looking forward to trying everything one bit at a time, lol. Thanks for the brainstorming!

#18 Libraries... sheesh.

#19 Yup. Now it runs, but I just have to figure out why I can't build a PhysX scene... sigh. :-P