Dynamic library naming issues

BOINC applications may include dynamically-loaded libraries (.dll on Windows, .so on Unix).

The search order for libraries is:

1. The project directory
2. The slot directory
3. other directories

Recall that BOINC files are immutable. Suppose that an app version uses a dynamic library with the physical name example.dll. There will be name collisions if either

• You support multiple platforms (say, Win32 and Win64), and there are different versions of the library for each platform.
• You need to update to new versions of the library.

Name collisions can be avoided by giving the libraries physical names that encode the platform and version number, e.g. example_win32_1_17.dll and example_win64_1_17.dll.

It may be inconvenient to rebuild the application to refer to these names rather than example.dll. To avoid this, include something like

...
  <file>
    <physical_name>example_win32_1_17.dll</physical_name>
    <logical_name>example.dll</logical_name>
    <copy_file/>
...

in your version description file. This tells the BOINC client to copy the library to the application's slot directory with the name example.dll. When the application tries to load example.dll, it will look in the project directory and not find it; then it will look in the slot directory and find it there.

.NET applications

.NET does not use the current directory as a search path for dependencies.

A workaround is to install a handler for the AssemblyResolve event and use the current directory (slot) to load the dependencies: