Need help with deployed application that depends on external DLL

I've been dealing with an MLAPP based dialog that needs to use a decryption DLL in order to load a file. This worked OK when running inside MATLAB, but I needed to create a "deployed" application. The challenge I am facing is that the DLLs are not picked up when the application first starts, creating the "mcr" subfolder. All the other .m and .mlapp files are compiled, or whatever actually happens there, and wind up under "mcr", but the DLLs do not. If I copy the DLL (and the associated "thunk" DLL that you get when creating the prototype file from the header file) over to the appropriate folder under "mcr", it works.

I was reading through the help files, specifically

Access Files in Packaged Applications - MATLAB & Simulink (mathworks.com)

and it does describe a way to explicitly load files in other locations. That would be great, but I guess I'm still confused how to do this.

The relevant line in the .m code is:

loadlibrary('mcrypto', @mcryptomfile);

The library itself is <path>/mcrypto.dll and the mcryptomfile is the prototype file.

Another challenge I face is that I have to do a Jenkins build in order to test changes as that's the only place we have a compiler license. This takes about an hour so it is not conducive to trial-and-error approaches.

Thanks for any hints!

Answer 1

[Martin]

Hi Gary,

Are you sure you include the mcrypto.dll file to the compiled executable?

With a command line compilation it looks like:

mcc -o MainCrypto -W WinMain:MainCrypto -T link:exe -a <path>/mycrypto.dll

where MainCrypto.m is your main matlab-file and MainCrypto.exe is the generated executable.

Martin

[Gary]

HI Martin, thanks for your answer. The honest answer to you is "probably not". In reality this is part of a much larger application for which I do not have direct control of the build process. As I don't have a MATLAB compiler license outside of the context of our build server, I'm not even able to test that in isolation. Up to now, this functionality has not been needed, so I'm pretty sure nobody ever did anything to support it.

As it stands, this particular version of our application is a one-off, not for general release, and we've decided it's ok to deal with it by copying the DLLs to where they will work after launching the main application. However, if it comes up again, I'd like to provide a path by which we don't have to do that.

Your answer does seem reasonable.

Best regards,

Gary W.

[Martin]

You are welcome.