Runtime SDK for .NET 100.15 (WPF) - Visual C++ redistributable requirements
Accepted Solutions
Hi,
There are two parts to the VC++ redistributable, one part Microsoft considers effectively part of the OS and it's installed with Windows and serviced through Windows update - that's the Universal CRT or UCRT. The second part is the Microsoft Visual C++ 2015-2022 Redistributable or vcruntime and it either needs to be installed or included with your app. Often you'll find it is already installed on a machine where other installed applications also depend on it and they have installed it as a prerequisite. That's still the recommended option because again it can be serviced by Windows or corporate updates. The other option for deploying it is an app-local deployment where you bundle the VC++ runtime dlls with your app. Traditionally many developers have favored this approach because it isolates the app from the impact of software updates to centrally installed components. We try not to lock developers into either approach and therefore list it as a prerequisite in the system requirements.
You can find more info about the centralized vs app-local approaches here:
Deployment in Visual C++ | Microsoft Docs
Determine which DLLs to redistribute | Microsoft Docs
Universal CRT deployment | Microsoft Docs
To determine if a deployment machine already has the vcruntime installed you can check installed products e.g.
I only have 14.28.29914... and ArcGIS Runtime works fine, but in the System Requirements topic we list the version we compile with/against (14.32.31326).
If you choose the app-local approach then you'll need to ensure the following vcruntime dlls are present on the system (either included with your deployment or you own installer could include the downloadable x86/x64 installers) - they should be included in the same folder as the ArcGIS Runtime architecture-specific runtimecore.dll:
- vcruntime140.dll
- vcruntime140_1.dll
- msvcp140.dll
- msvcp140_1.dll
- msvcp140_2.dll
- msvcp140_codecvt_ids.dll
It seems like we should review our doc in this regard and perhaps we could provide greater clarity - I'll open an issue to assess.
Thanks
Hi,
There are two parts to the VC++ redistributable, one part Microsoft considers effectively part of the OS and it's installed with Windows and serviced through Windows update - that's the Universal CRT or UCRT. The second part is the Microsoft Visual C++ 2015-2022 Redistributable or vcruntime and it either needs to be installed or included with your app. Often you'll find it is already installed on a machine where other installed applications also depend on it and they have installed it as a prerequisite. That's still the recommended option because again it can be serviced by Windows or corporate updates. The other option for deploying it is an app-local deployment where you bundle the VC++ runtime dlls with your app. Traditionally many developers have favored this approach because it isolates the app from the impact of software updates to centrally installed components. We try not to lock developers into either approach and therefore list it as a prerequisite in the system requirements.
You can find more info about the centralized vs app-local approaches here:
Deployment in Visual C++ | Microsoft Docs
Determine which DLLs to redistribute | Microsoft Docs
Universal CRT deployment | Microsoft Docs
To determine if a deployment machine already has the vcruntime installed you can check installed products e.g.
I only have 14.28.29914... and ArcGIS Runtime works fine, but in the System Requirements topic we list the version we compile with/against (14.32.31326).
If you choose the app-local approach then you'll need to ensure the following vcruntime dlls are present on the system (either included with your deployment or you own installer could include the downloadable x86/x64 installers) - they should be included in the same folder as the ArcGIS Runtime architecture-specific runtimecore.dll:
- vcruntime140.dll
- vcruntime140_1.dll
- msvcp140.dll
- msvcp140_1.dll
- msvcp140_2.dll
- msvcp140_codecvt_ids.dll
It seems like we should review our doc in this regard and perhaps we could provide greater clarity - I'll open an issue to assess.
Thanks
