Shipping windows exe, where to source msvcp etc?

Hello,

Sorry for the long post, I'm not sure this is even a swift question, but my windows programming experience is slight enough that I don't know where else to look.

We have been deploying a x-plat swift app on windows for a few months now. Things have been working well. To date we've been locally packaging all the dlls used by the app, basically by trying to launch the app on a bare machine and progressively adding dlls that windows attempts to link and fails.

These seem to fall into two categories:
swift runtime dlls and windows dlls, both copied from

C:\Users\<user>\AppData\Local\Programs\Swift\Toolchains\6.0.0+Asserts\usr\bin

However I just ran into a problem I haven't experienced before. My app compiles and runs fine in vscode. It even ran by invoking directly from the build folder. However, after following the steps above to package up the app for deployment, it was crashing - even on my development machine. I eventually tracked it down to a STATUS_ACCESS_VIOLATION in msvcp140.dll. Removing this file (which I assume falls back to using the version in Windows/SysWOW64) fixes the problem. I noticed the one in the Windows dir has a newer version.

So finally, my question. Where should I be sourcing files like msvcp140.dll? Is there a reason swift has an older copy installed than my system? I tried repairing the install thinking that file was being copied over by the swift installer, but it remains the same older version.

I'm just trying to understand how this all works together. Is the dll in the swift toolchain even used, if it appears my app running in vscode is using the system version not the one in the toolchain?

I just want to say, it really is a testament to this project that I'm making and shipping an app without having any clue how all these windows details even work :)

Thanks,
mike

I'm not sure of the Swift specifics, but in general you shouldn't be copying the C++ runtime DLLs manually. Microsoft wants you to run their redistributable installer when installing things that have a dependency on the C++ runtime.

The versions since 2015 (140) have been binary compatible, so you should be good to use the latest in your installer, but testing will tell you if that's the case.

2 Likes

Just checked my Swift 6.0.2 installation, and there is no msvcp140.dll file in the C:\Users\<user>\AppData\Local\Programs\Swift\Toolchains\6.0.2+Asserts\usr\bin folder on my Windows 11 machine.

TBH I don't know the right source of runtime dependencies, especially if they can be found in several places. I rely on this utility.

C:\Users\<user>\AppData\Local\Programs\Swift\Runtimes\6.0.2\usr\bin\

1 Like