DLL paths, using vcpkg

I have a few questions about DLL paths on Windows.

I’m on Windows 10. I’ve just used Visual Studio Community 2019 and vcpkg with Power Shell to install 64-bit libraries needed for a project. All the required libraries have all been installed on the machine and reside in the following directory:

C:\\Users\\Admin\\source\\repos\\vcpkg\\packages\\

Each library is inside its own folder there, and each dll is (in some cases many DLLs are) inside a bin folder, so the entire path to any given DLL looks like this:

C:\\Users\\Admin\\source\\repos\\vcpkg\\packages\\library_folder_name\\bin\\lib_name.dll

When I use this path as a constant to access the library I need, System.IsFunctionAvailable returns false. This doesn’t tell me if the library was found or not, whether the function doesn’t exist in the library, or if a dependent library wasn’t found. I’m assuming I’m missing something basic about how this works.

In the past I have always placed DLLs next to the .exe file both for debugging and in built applications. I tried that today with these libraries and it did not work. The DLLs are all 64-bit, and my app is 64-bit. I know all the dependencies are installed on my machine.

So my questions are:

  1. What does the path to a DLL have to be in Xojo for the IDE to find the DLL, (a) in a DebugBuild, and (b) in a built application?
  2. After Xojo finds a DLL, how will it find all of the other DLLs required as dependencies?

[quote=450722:@Aaron Hunt]
So my questions are:

  1. What does the path to a DLL have to be in Xojo for the IDE to find the DLL, (a) in a DebugBuild, and (b) in a built application?
  2. After Xojo finds a DLL, how will it find all of the other DLLs required as dependencies?[/quote]

Normal Windows DLL location rules apply
https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

[quote=450731:@Norman Palardy]Normal Windows DLL location rules apply
https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order [/quote]

Thank you. That clearly answers my second question.

I’m still not clear on the first question. Let me rephrase the problem after having read through the microsoft page …

It appears easiest and most secure to put all the DLLs right next to the .exe file. What is the path I need to put in Xojo to access those .dll files? Is it simply the library name? Is there a backslash anywhere?

Sorry to be dense but beyond compiling the apps I write on the Mac for Windows and sometimes addressing Windows-specific problems to get the Windows version to work properly, I don’t use Windows at all.

Its the answer to both actually

to load them you just use the DLL file name and the search path will FIRST look right next to the built exe

if you put them elsewhere I expect you’ll need a full path to them

this is why MS encourages people to just put the DLL’s right next to the EXE - its the first place searched

[quote=450741:@Norman Palardy]Its the answer to both actually

to load them you just use the DLL file name and the search path will FIRST look right next to the built exe[/quote]

Okay, thank you. I think I get it now.

Unfortunately it doesn’t work when I do exactly that, but I guess I must be missing a dependency, or I haven’t put the DLLs in the right place for a DebugBuild session. Do I have to do a Run/Paused and copy them over? (I’ve tried using “Copy Files” Build Step before but it has never worked for me.) I thought if they are in the same directory as the Xojo project file, that should work?

[quote=450742:@Aaron Hunt]
Unfortunately it doesn’t work when I do exactly that, but I guess I must be missing a dependency, or I haven’t put the DLLs in the right place for a DebugBuild session. Do I have to do a Run/Paused and copy them over? (I’ve tried using “Copy Files” Build Step before but it has never worked for me.)
for a debug build they still need to be RIGHT NEXT TO THE DEBUG EXE itself
On Windows this can be inside a folder
IF you use a copy file step to copy them there use “app parent folder” as that will copy the DLL’s into the same dir the EXE is in
If you run paused they still need to be copied RIGHT NEXT TO THE DEBUG EXE

No
having them next to the project is not going to work as its not one of the places Windows searches for DLL’s

[quote=450744:@Norman Palardy]for a debug build they still need to be right next to the DEBUG exe itself
On Windows this can be inside a folder
IF you use a copy file step to copy them there use “app parent folder” as that will copy the DLL’s into the same dir the EXE is in[/quote]

Okay, of course. I am really being inexcusably dense here. I get it now :slight_smile:

I am apparently still doing something wrong when I make a “Copy Files” Build Step, because the files do not get copied. I have done this:

  1. click on menu Insert > Build Step > Copy Files
  2. drag all the DLL files into the window, and they all show up with a …/ path
  3. select Destination: App Parent Folder (this is actually the default, so nothing to select)

When I run it, the files are not copied. I verified this by looking in the Debugbuild folder where the .exe lives (the App Parent Folder) during the DebugBuild session. I must be missing a step?

is the step AFTER the BUILD for Windows ?
http://great-white-software.com/miscellaneous/CopyFiles.png

Aha. Thank you, that is the step I was missing. Now the files are copied. So there are in fact 4 steps:

  1. click on menu Insert > Build Step > Copy Files
  2. drag all the DLL files into the window, and they all show up with a …/ path
  3. select Destination: App Parent Folder (this is actually the default, so nothing to select)
  4. drag the build step icon, (CopyFiles1 or however one has named it) at left in the Navigator down under the Build Settings heading, and put it under the platform for which the step should be executed, making sure it is ordered logically.

Am I wrong, or is this information nowhere to be found in the Xojo docs? In the past I had done forum searches on this and never found this information stated clearly anywhere.

Anyway, now all the DLLs are there next to the DebugBuild .exe file :slight_smile: … Unfortunately, System.IsFunctionAvailable is still returning false :frowning:

all covered in the users guide too
http://documentation.xojo.com/topics/build_automation/introduction.html

[quote=450762:@Norman Palardy]all covered in the users guide too
http://documentation.xojo.com/topics/build_automation/introduction.html [/quote]

Great! I had never seen that. Hard to believe I haven’t been able to use this feature until now, out of sheer ignorance. Thanks :slight_smile:

Apparently something is not right with my DLLs, but at this point I think I should ask for help from the authors of the library I am trying to access. There must be some dependency I’m still missing.

Thank you again for all your help, Norman.

In case anyone else might run into this, I found out the cause of my problems with the DLLs is simple and general and not specific to these libraries.

It turns out that vcpkg defaults to downloading 32-bit libraries. So to my great embarrassment, all the libraries I have installed are 32-bits. Once I found this out, I changed the Xojo build settings to 32-bits and tested my app, and it worked.

Well, I want 64-bits for this project, so I am now installing the right libraries with vcpkg. I expected that since I’m running 64-bit installation of Windows 10, then the microsoft tool vcpkg would know this and default to installing 64-bit libraries, but it does not do this. To me that is really not at all logical. Anyway, the trick I did not know I needed is to add the option “–triplet x64-windows” to the install command:

.\vcpkg install library_name --triplet x64-windows

The environment variable for vcpkg default behaviour can also be changed to get 64-bit libraries without having to type in the option. The steps needed to do this in Windows 10 seem a bit ridiculous to me, but I did it anyway and maybe you will want to do it too, so here they are:

  1. Click Windows Start and then click on “Settings” (this used to be “Control Panels”)
  2. Click on “System”, and type in the word “environment” into the search field
  3. Select the option that reads “Edit the System Environment Variables”
  4. in the window that appears, click the “Advanced” tab
  5. at the bottom right, click the “Environment Variables” button
  6. Under the “System Variables” pane, click the “New…” button
  7. create a new variable with this info:
    name: VCPKG_DEFAULT_TRIPLET
    value: x64-windows

Now when you use vcpkg at the Power Shell command prompt, you do not need to type --triplet x64-windows to get 64-bit libraries :slight_smile: