After seeing this conversation on the forums, I thought it would be helpful to run through why you can move some of your app’s DLLs but you cannot move others.
On Windows, the Visual Studio C Runtime DLLs can be in one of two locations on systems that do not already have them installed. All versions of Windows prior to Windows 10 would need these installed.
Arguably the “best” place is to install them in the Windows\System directory so that normal OS updates will keep them up to date. This requires the use of an installer as putting files in the Windows\System directories needs elevated privileges.
The other place they can be is right next to the app executable itself — but not in a subdirectory like plugins can be.
Why can’t they be in a subdirectory like plugins? When the OS starts to load and execute your application the OS loads whatever DLLs are required as part of starting the app. These required DLLs must be available where the OS finds them; not where the Xojo framework would because your app isn’t running yet. And since the app isn’t running yet the app cannot alter where the OS looks for them.
Normally Windows looks in these locations:
- The directory where the executable module for the current process is located.
- The current directory.
- The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.
- The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.
- The directories listed in the PATH environment variable.
For plugins, the Xojo runtime is specifically loading the DLLs using LoadLibrary and in that case the framework can tell exactly where to look (and where not to look) for the required DLLs which is why they can be in <appname> Libs or just Libs. And this is why the Visual Studio C Runtimes cannot be moved but plugin DLLs can be.