Plugin not Being Loaded

[vertigo]

Mike,

I sent a published file (.exe) to someone and for some reason the .dll is not being loaded. I am calling (loadplugin) in LISP.

When double checking the documents on publishing I noticed this paragraph and I'm not sure what they are saying.


You can also select plugins in the Available Assets list. The single 'Plugin Scene Code' entry area is a way to place all their code into a single DLL without having to call (LoadPlugin).


Where is the " 'Plugin Scene Code' entry area " ?

Any thoughts?

[Radishworks]

Whoops! That comment you quoted, is no longer valid. It used to be you could pick a single plugin in the publish dialog. This is obsolete with the (loadplugin) function. I've updated the docs.

As far as your plugin not loading, assuming it is present in the published .exe - check to make sure it is selected in the assets list in the publish dialog. If it is selected and still doesn't load, I would guess that your .DLL needs some other .dll that your end user needs. If it works on your machine but not your user, I'd bet that's the issue (because that one has fooled me before too).

Hope that helps.

Mike

[vertigo]

Its checked in the asset list in the publish dialog but I wonder if the user might need the Visual Studio 2008 distribution DLL's?

Recently I did a small project for motion control and used VS2008. Even though I was not calling any special Windows functions the application would not run until the VS2008 redistribution "stuff" was installed with the app. I guess it might be something like the VS2005 redistribution pack.

I'll have to do some additional research and I'll let you know.

Cheers!

[Radishworks]

Yep, I'll bet that's it. We fought the same thing with EC itself.

Look for: vcredist_x86.exe. This should install the right stuff.

[bmistal]

Try using this tool. It it awesome for tracking what extra dll's an application or plugin may require to run.

http://www.dependencywalker.com/

[vertigo]

Thanks for the quick response and it sounds like we all agree that this is most likely a VS2008 issue.

Ben, thanks for the new tool this will come in very handy for future projects.

[vertigo]

Guys,

I tried Dependancy Walker and surprise....surprise I see a VS2008 DLL being called. I attached a screen shot.

This makes for an interesting question. Should we document, if using VS2008 they need to include the redistribution "package" with their applications?

Another thought... What happens if I release a .esp file that calls a DLL created by VS2008. Because you are using VS2008 to compile the EC Viewer I wonder if this will NOT be an issue.

Food for thought...and maybe a little more testing???

***UPDATE***

Good read that explains a little more detail about the DLL's I'm talking about if you compile with VS2008.

http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx

If you are looking for these DLL's they should be installed with your copy of VS2008. Mine are located in the following path:

C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT

[Radishworks]

I added a note in the docs about this little .DLL "got-ch-ya".

Yes, this will be a problem with a .exe or a .esp that needs any other .dlls by your plugins.

I'm pretty sure that the EC viewer runs without the need for any extra .dlls - we tested that pretty heavy before release. If your delivered .EXE ran at all (just the .DLL didn't load) then that confirms the ECV doesn’t need the VS2008 extra .dlls.

M :-)

[vertigo]

Sounds good Mike.

It would be nice to pack everything into one nice and neat package. I'm wondering if its possible to pack third party DLL's with the EC file?

I think I remember reading about that in the docs somewhere.

[Radishworks]

I'm wondering if its possible to pack third party DLL's with the EC file?

Maybe, but there are issues that come to play here. Mainly copyright ones, if we were to automaticly snag .dlls from 3rd parties, we could grab .dlls that we shouldn't. Not to mention the technical problems with doing so.

M

[vertigo]

Mike....yes I agree, automatically including DLL's would be a big mistake. I was thinking more along the lines of the ability to include files via API or Script?

I have not taken time to look yet but I thought we had that feature?

[Radishworks]

Ahh, yes. I think I know the feature you are talking about.

Check out the callback: AddPackageFiles

It allows the developer to add thier own files. The problem is that windows will only load .DLLs from disk in a path it can find - i.e. exe location, etc. So the developer would need to save the extra .dlls to disk manualy (the ec_GetPackageFile() file can be used for this).

Problem is this... Windows won't load a plugin until after it can find all the .dlls, and the plugin will need to be loaded before the ec_GetPackageFile() can be called. Unless there was a stub plugin that would save the .dlls before the real plugin dll was loaded. Cart before the horse / chicken and the egg thing.

Welcome to the wonfderful world of installing .dlls. :-(.

Mike

[vertigo]

So I guess you have two potential solutions to delivering one file to clients.

(1) Package everything in one installer/ setup file. I personally like http://www.jrsoftware.org/isinfo.php its free and very easy to use.

(2) You could use a wrapper program like:

http://www.molebox.com/

http://www.aspack.com/

http://www.strongbit.com/execryptor.asp

I have not tested any of these wrapper programs so be sure to test before you start delivering your applications.

Awesome post I learned a lot here...thanks Ben and Mike.