Visual C++ Debug Runtime Redistributable

[Ilse Marseau]

Iam developing a commercial software that is based on Visual Studio 2017 Pro infrastructure (MSVC and CMake) on Windows 10. The software has 3rd party dependencies that require the debug version of the VC++ runtime, whenever I debug my software.

I would like to know if I can use the library (from the VS2019 CE installation) for the development of my commercial product, while employing VS2017 Pro for everything else? Does this go against the EULA?

The EULA mostly governs behavior, and the behavior of using CE assets in the development of commercial software seems to be incompatible with the CE EULA. Seeing as the edition you obtained the libraries from is something you want to be able to answer for when developing commercial software, you should behave in accordance with the EULA.

Something else to keep in mind is the redistributable installers may also include their own EULA, so ensure you comply with those terms as well. However, even if it does have a separate EULA, you still want to obtain the debug redistributable in a proper way. If installing CE is how you obtained that redistributable, you are still bound by CE's EULA.

Apps built by using Visual C++ require the vcruntime and other libraries to run. Debug versions of apps often require the corresponding debug versions of the libraries. You must deploy these libraries on your test machine to test the debug version of your app. To identify which DLLs you must deploy, follow the steps in Understanding the dependencies of a Visual C++ application. Typically, debug versions of Visual C++ library DLLs have names that end in "d". For example, the debug version of vcruntime140.dll is named vcruntime140d.dll.

Debug versions of an application aren't redistributable, and debug versions of the Visual C++ library DLLs are also not redistributable. You may deploy debug versions of applications and Visual C++ DLLs only to your other computers, for the sole purpose of debugging and testing the applications on a computer that doesn't have Visual Studio installed. For more information, see Redistributing Visual C++ files.

Use central deployment to install a debug version of a particular Visual C++ DLL to the %windir%\system32\ directory. You can deploy the debug DLLs by using a Setup project that includes DLLs for the library version and target architecture of your application. You can see an example of a deployment project in Walkthrough: Deploy a Visual C++ application by using a setup project.

Use local deployment to install a debug version of a particular Visual C++ DLL in the application's installation directory. For more information on where to find the non-Redistributable debug DLLs, see Determine which DLLs to redistribute.

We have found that on the host PC this functions correctly in both the dev environment and built executable (though we do intermittently receive error 7171 and error 7156, it seems like retrying a couple times will connect).

The DLL is found in the dev environment because it is loaded in memory with the project. And even when you run an EXE on the dev environment, it is found because you most likely still have the project open and loaded in memory. My guess is that if Labview is shut down and you try to run the EXE that it will also fail on the dev computer.

The DLL should not be Always Included in the EXE. Try saving it to a support directory when compiling the EXE and make sure the Call Library function has an appropriate relative path to the DLL in the support directory. You might want to drop a path indicator on your FP where you can check that the path is what you expect it to be.

As aputman mentioned, you should not always include the DLL in the application. In addition to his advice, it seems likely that the errors you are receiving on your development machine are not related to the errors on your deployment machine. I found this article which may be helpful to read through:

It's likely that your executable doesn't know how to find either the DLL, or dependencies of your DLL. You can add a line into the DLL for the config file for your DLL, or the executable to tell it where to look.

Also did you distribute the Release or Debug build of your DLLs? The debug built can normally only run on a computer where the Visual C Debug runtime library installed, which is installed with Visual C but there are no redistributables of that to install on other machines and neither is Microsoft giving out licenses to do that legally.

In the last several years, Arm chips have made the leap from powering consumer cell phones to laptops. Powerful, lightweight, and always connected, Arm presents a new future for personal computing devices that users can take with them anywhere.There are numerous Windows 10 Arm devices on the market from manufacturers such as Microsoft, Lenovo, and Samsung. Users can run 32-bit x86 versions of their favorite programs in emulation, but that comes with performance trade-offs. 64-bit x86-64 programs simply do not run. As the install base grows, there is increasing demand for applications and games that can run natively on this hardware and take advantage of all it has to offer.Developers want software to be available to as many potential users as possible, and for that software to run without compromise. However, additional platforms often carry a significant amount of additional work.This general development guide describes the work and collaboration between Microsoft and Qualcomm to make porting software to Windows 10 on Arm as streamlined as possible.The following sections walk users through these processes and features from the comfort of their current x86-64 development environment:

This guide assumes existing knowledge and experience with software development, basic familiarity with Visual Studio and associated tools, and an understanding of x86/x86-64 systems. It also assumes that development work will be performed on an x86-64 Windows 10 device. At the time of writing (May 2020), development tools such as Visual Studio and Unreal Engine Editor do not run natively on Arm64 but can build applications and games to Arm64 targets.

This section provides the necessary steps to enable Arm64 Development in Visual Studio. Both Visual Studio 2017 and Visual Studio 2019 are configured similarly. Examples provided in this guide use Visual Studio 2017.

On-device and remote debugging are both valid options for debugging an application. This guide focuses on remote debugging so that users can continue to work from the comfort of their development environment.

Remote debugging allows users to debug their application directly from Visual Studio on their development host machine. This allows users easy access to their favorite tools even if they do not have native Arm64 equivalents.

Applications compiled by Visual Studio depend on the libraries of the Visual Studio runtime. These libraries were installed on the Arm64 development target when the Windows 10 SDK and the remote debugging tools were installed.

To run, or remotely debug Arm64 executables compiled in the Debug configuration, the debug version of the runtime libraries must be installed on the Arm64 system. These libraries are not provided by the Visual Studio runtime redistributable (see Distributing the application).

If the computer is not on a Domain, WinPixRemoteMonitorUI.exe provides a warning during startup that it cannot run on a secure connection. To proceed, switch the Connection mode to Insecure in the UI.

The Gold cores offer higher performance, while the Silver cores have better thermal and power characteristics. The variation in performance between these cores are because of frequency and architectural differences.

Other architectures, such as amd64 also use weakly-ordered memory. If you are using high-level threading APIs, these problems are handled for you. However, users who are porting their own implementation of low-level multithreaded code must use the appropriate memory barriers and other configuration for the hardware platform.

Visual Studio supports Neon intrinsics. New Neon code can be written in parallel with existing SSE code and enabled at compile time for porting. It is also worth noting that the Arm Compute Library is available, and provides Neon-optimized implementation of commonly used algorithms.

Tiled-based rendering is a render pipeline architecture that splits the screen into several tiles and renders each tile in succession. Compared to the direct rendering model favored by older desktop GPU technology, this greatly reduces memory bandwidth, which reduces power consumption and improves performance.

If you are porting from an older, rendering architecture, ensure that the rendering pipeline is optimized for a tiled renderer. Using a deferred renderer and reducing shader counts will yield the best performance improvements when moving from an immediate mode GPU to a tiled GPU.

The Adreno 680 also benefits from the unified memory architecture of the Snapdragon 8cx SoC. Compared to discrete desktop GPUs, there is no distinction between operating system memory and GPU memory, which allows the following:- Better use of resources depending on CPU or GPU intensive tasks- No transfers between central and GPU memory- Less overall power consumption

Windows is maturing, but there is a still a long path to get to the point where we should start thinking about ABI stability. Similar to how Apple platforms prior to ABI stability, Windows will require shipping the runtime as part of application distributions for some time.

There have been previous threads on the forums about the difficulty about the packaging.

A discussion with @etcwilde about Windows made me realise that one piece that we are currently missing in the toolchain installation is a MSM for the runtime. This is something Visual Studio already does for the redistributable (though it is deprecated as it simplifies updates with versioning).

I was curious if people who may be interested in distributing the redistributable, would it be more convenient to have the redistributable available as a MSM or a MSI? The latter would always require that the application redistribution is in a bundle to install the chain for the dependency (similar to the installer.exe for the Swift toolchain).

3a8082e126