= Dynamic library naming issues = Suppose your application uses a dynamic library, say '''example.dll'''. Recall that [BoincFiles BOINC files are immutable]. If you use the physical name '''example.dll''' there will be a problem if either * You support multiple platforms (say, Win32 and Win64), and there are different versions of '''example.dll''' for each platform. * You need to update to new versions of the library. The easiest solution is: * Give the libraries physical names that encode the platform and version number, e.g. '''example_win32_1_17.dll''' and '''example_win64_1_17.dll'''. * Use '''example.dll''' as the logical name. To do this, use something like the following in your [AppVersionNew#Theversiondescriptionfile version description file]: {{{ ... example_win32_1_17.dll example.dll ... }}} The '''copy_file''' flag tells the BOINC to copy the library to the application's runtime directory. == Avoiding name conflicts == The search order for libraries is: 1. The project directory 1. The slot directory 1. other directories Hence if you use '''example.dll''' as a physical name in one app version, other app versions will use that library even if they use the above scheme. To avoid this problem, use logical names that don't conflict with physical names. == .NET applications == .NET does not use the current directory as a search path for dependencies. Our workaround is to install a handler for the AssemblyResolve event and use the current directory (slot) to load the dependencies: