2

This is something new for me, and the question is probably more about the Delphi IDE than the code.

I want to develop a DLL and two applications which will use it.

I made a very basic DLL and a quick dummy app to test it. So far, so good. BUT, all the source was in a single directory.

I feel that I probably ought to have a group project containing three projects (DLL + 2 apps).

But how do I get the apps to use my DLL during the development phase?

I don't want to copy it into the windows system directory while I am in the process of develop it, but when I add it's directory to the app's search path it is not found.

How do I configure my app projects to use the still in development DLL?

[Update] Wow, my quickest ever down-vote. One minute! And, as usual, not even a comment to say how I offended, other than asking for help.

I have googled, and I have read the help. But I can't see how to do it, so am asking for help.

Mawg says reinstate Monica
  • 38,334
  • 103
  • 306
  • 551
  • 1
    Any reason you can't just add it to the [search path](http://msdn.microsoft.com/en-us/library/vstudio/7d83bc18.aspx)? – Nick Barnes Nov 29 '13 at 10:20
  • 1
    To hardcode it you may write `{$IFDEF DEBUG}SetDllDirectory('C:\DirectoryWithDLL');{$ENDIF}` in your applications somewhere before the DLL is loaded. But I wouldn't personally do that. – TLama Nov 29 '13 at 10:27
  • @TLama The downside of that is that it does force you to use runtime linking which is generally less convenient. – David Heffernan Nov 29 '13 at 10:29
  • @David, or you may use `delayed` directive. But as I said, I wouldn't do that. – TLama Nov 29 '13 at 10:31

1 Answers1

5

The preferred way to enable an application to see a DLL is for the DLL to be located in the same directory as the host executable.

I typically do that by having a project group with executable and DLL. Make sure that all the projects output their executables to the same directory. If the .dpr and .dproj files are all in the same directory, and the default output directory of .\$(Platform)\$(Config) is used, then all will be well. All executable files land in the same directory, and the loader will find them.

Doing it this way has a number of benefits:

  1. No need for any post-build actions to copy files around.
  2. Debugging works well. You can step into and out of the DLLs, and step through source.
  3. You can rebuild all the executables in one go using the Project | Compile All Projects menu item.

An aside. You said:

I don't want to copy it into the Windows system directory while I am in the process of develop it.

Well, please don't ever copy it into the system directory. That directory is private, it is owned by the system. You should not place files there.

When you come to deploy your application onto other machines, you should prefer the option of placing executable and DLLs in the same directory. That's the simplest deployment technique, and the most secure and maintainable. That's the method that avoids DLL hell.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • +1 and the answer. Thanks very much as always, David. That way I can have my separate projects and separate source directories, and just put the output (.EXEs and .DLL) into a single directory and everything is fine. And, yes, I agree with you about deployment too. – Mawg says reinstate Monica Nov 29 '13 at 10:38
  • 1
    This is very bad advice. What if DLL supposed to be shared across several applications (OP's original intention)? What is those applications **are not** interrelated and not supposed to be in the same directory (as you advocating)? – Free Consulting Nov 29 '13 at 11:23
  • 2
    @FreeConsulting That's known as DLL hell. This is the modern way. There's always WinSxS. Lots of fun to be had there. Or runtime linking. And so on. – David Heffernan Nov 29 '13 at 11:25