Didn't have any bites:
Publish loses dll

Any thoughts?

Im not a big boy, but anyway, you know about how to publish files, pragma_bind and so on?

#define PRAGMA_BIND "mydll.dll";

This copies your DLL into the target folder.

Im too lazy for this though and normally copy the DLLs with Win Explorer drag and drop.

Haha, yeah, I generally drag and drop too. It seems like publishing the project incorporates the dlls into the resulting acknex.dll, cause when I try to copy the dlls into the executable folder, the executable crashes immediately, but when I leave em out, the program runs without a hitch...minus one of my dll's ability (the same one appears missing regardless of which dlls exist in the exe folder). The dll that isn't activating is the same one I've used unchanged for months, so I'm very confident that it is working properly. I've got 5 dlls altogether, and I've tried every combination of them in the exe folder with no luck.

Has this "problem" dll ever worked published ever?
There may me a function in it that has the same name as an internal functin
built-in to acknex.dll. Causing the crashing when the dll's get merged.

Try taking any pragma_binds for "that" dll out and publish, then copy the
dll manually and see if it works then.
If it does, you may need to do that every time you publish, or the "good"
way would be to re-name all the functions in "that" dll make sure they are
TRULY unique names.

Hope this helps.

A DLL is just a library of functions that are loaded at runtime. When your project crashes when loading the DLL, but does not crash when the DLL is not there, there are two possibilities. Either it's a crash in a DLL function itself. Or a script functions crashes when it calls a DLL function which returns something that is not expected.

If it happens randomly or only when the project is published, you can't debug your script directly. But you can debug the DLL if it's your own DLL. If it's a DLL of which you don't have the source code, check with diag outputs which of your script functions crash. This should normally give you an idea what's wrong.

Alright, time for an update. We are certain that the issue is related to our app's interaction with the DLLs since we can take the DLLs out and everything else works fine. What's strange is that our app runs flawlessly from SED and WED, but crashes in a built project (and yes, I've made sure that the dlls are copied into the build folder). Even stranger- I noticed that if I didn't kill the app immediately when it crashes, the program actually continues without a problem, even utilizing functions from the DLL. Unfortunately I don't know any way to suppress the crash dialogue, and if you close the dialogue box, the whole app goes away. Our DLL actually references a third DLL. At one point, it seemed like the executable would crash because of the third DLL (since it looks like A7 tries to open any dll in the exe folder, and crashes if it is unsuccessful), so we moved it to a subfolder and changed the way we referenced it in our DLL. That got rid of the invalid memory read error, but the build still crashes immediately on running. We're pretty baffled.

@EvilSOB for sure we've had published builds that worked with our dlls. I did numerous published testing trials at various stages. What's frustrating, is I can't even seem to get back to any working version. I have backups through last September, but none of them work anymore.

I've tried reinstalling A7.

Out of curiosity, what does SED do differently from the built exe?


Ok- a lot has happened since I began to write this post. My boss stepped in to help me out and he discovered some very odd behaviour:
-On my computer, the built version finds the dll, but causes a crash with unhelpful dialogue (though the program continues to run correctly, including utilization of the dll)
-On my bosses computer, the same build works without issue.
-On a third computer, the app can't even detect the dll

This is very strange indeed.

Currently, we are trying to rewrite our dll in lite-c with LoadLibrary. I'm still interested in why what runs in SED is different from what is built into the exe.

Thanks for reading!

Try doing a scan on 'your' computer for duplicates of your awkward dll.
There may be an old version somewhere thats been 'registered' by windows
and is over-riding your new one, or there may be a dll "for some other app"
that has the same name as yours, and its running interference.

When you've written the DLLs, can't you just place breakpoints in their functions and check what they return? Normally you should be able this way to find and fix bugs of this kind in a couple of minutes.

Alas, we don't have the source for all our dlls- one of the dlls is from our client.

@EvilSOB: I'm pretty sure we don't have any duplicates, but I'll double check. When you say that dlls are registered in windows, is this something we can check with a utility? i.e. can I look at the registry and see where it's running from?

We finally got this working (on all but one anomalous computer). Instead of dropping the dll in the top layer, we now put it in a sub-directory and then call LoadLibrary from our own dll in an initialization function that I call from main in SED. It's still unclear what the problem was, but it might have been a timing thing- A7 trying to load a number of dlls asynchronously and getting confused? We've still got to test on Vista, but it looks ok for now.

Thanks all for your support!

\windows\system32\Regsvr32.exe is the tool to register/unregister the dlls.
But it doesnt seem to have a -list option to see a list of what is registered.

I would say just scan through the registry for the dll filename and if it turns
up in a registry folder called "components" then I think it is registered.
You CAN have multiple occurances of the same dll work OK side by side from
different folders, but sometimes they get tangled if the registration entry
does not contain a specific folder name, OR if two dlls with the same
NAME AND PATH but on different DRIVE letters exist.

Please note, this is largely theory, just logical thinking with a little
actual first hand experience thrown in.