= 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
 1. The slot directory
 1. other directories

Recall that [BoincFiles 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 [AppVersionNew#Theversiondescriptionfile 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: