Is renaming an unmodified Visual C++ Runtime DLL allowed for redistribution?

Question

Is renaming an unmodified Visual C++ Runtime DLL allowed for redistribution?

nhpokon 40

Subject:

We distribute a Windows x64 desktop application that includes the official

NumPy 2.5.1 Windows wheel.

That wheel was processed by delvewheel and contains the Microsoft Visual C++

Runtime DLL msvcp140.dll under a content-hash filename:

msvcp140-a4c2229bdc2a2a630acdc095b4d86008.dll

We verified that this DLL is byte-for-byte identical to msvcp140.dll from

the official Microsoft Visual C++ Redistributable 14.40.33810:

identical file size
identical SHA-256
valid Microsoft Authenticode signature
OriginalFilename remains msvcp140.dll
no bytes in the DLL were modified

Only the filesystem filename was changed by delvewheel, and the dependent

Python extension modules were adjusted to reference that name.

Microsoft's redistribution documentation refers to distributing the

Redistributable files in "unmodified form".

Could you clarify whether changing only the filesystem filename, while

keeping the Microsoft-signed binary byte-for-byte unchanged, is permitted

under the Visual C++ Runtime redistribution terms?

Specifically:

Does "unmodified form" apply only to the file contents, or also require

retaining the original filename?

Is filename-only renaming permitted if the binary and Authenticode

signature remain unchanged?

If not, should applications instead use the original msvcp140.dll name

or require installation of the official VC Redistributable?

Thank you.Subject:

Is renaming an unmodified Visual C++ Runtime DLL allowed for redistribution?

We distribute a Windows x64 desktop application that includes the official

NumPy 2.5.1 Windows wheel.

That wheel was processed by delvewheel and contains the Microsoft Visual C++

Runtime DLL msvcp140.dll under a content-hash filename:

msvcp140-a4c2229bdc2a2a630acdc095b4d86008.dll

We verified that this DLL is byte-for-byte identical to msvcp140.dll from

the official Microsoft Visual C++ Redistributable 14.40.33810:

identical file size
identical SHA-256
valid Microsoft Authenticode signature
OriginalFilename remains msvcp140.dll
no bytes in the DLL were modified

Only the filesystem filename was changed by delvewheel, and the dependent

Python extension modules were adjusted to reference that name.

Microsoft's redistribution documentation refers to distributing the

Redistributable files in "unmodified form".

Could you clarify whether changing only the filesystem filename, while

keeping the Microsoft-signed binary byte-for-byte unchanged, is permitted

under the Visual C++ Runtime redistribution terms?

Specifically:

Does "unmodified form" apply only to the file contents, or also require

retaining the original filename?

Is filename-only renaming permitted if the binary and Authenticode

signature remain unchanged?

If not, should applications instead use the original msvcp140.dll name

or require installation of the official VC Redistributable?

Thank you.

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Bruce (SqlWork.com) 85,201

This is user supported forum and you can not get definitive licensing answers. You should contact your Microsoft rep or open a support ticket.

Note: you could static link to avoid the issue.

nhpokon 40 Reputation points

2026-08-24T04:46:47.48+00:00

Thanks for the clarification. I understand that this forum can’t provide a definitive licensing answer. Your suggestion to contact Microsoft directly, and the note about static linking, were both very helpful. Thanks again.

Answer 2

Hello @nhpokon ,

I cannot give a definitive legal interpretation of the Visual Studio or Visual C++ Redistributable license terms in this Q&A forum. For a binding answer on whether a renamed runtime DLL still satisfies the applicable license language, please confirm with your Microsoft representative or open a formal support/licensing request.

From the technical documentation side, Microsoft documents redistribution as being limited to licensed Visual Studio users and subject to the Microsoft Software License Terms in Redistribute Visual C++ files. The same documentation describes the supported deployment options as installing the Visual C++ Redistributable package, using merge modules, or installing individual Redistributable DLLs in the application-local folder; it also says the Redistributable package is recommended because it enables Microsoft to service the runtime libraries independently.

So I would not treat a filename-only rename as something that Microsoft Q&A can approve as permitted. The conservative supported approach is to either install the official Visual C++ Redistributable package, preferably the latest supported package listed in Latest supported Visual C++ Redistributable downloads, or deploy the individual redistributable DLLs only as allowed by the applicable license and REDIST list. The Determine which DLLs to redistribute article also recommends central deployment through the Redistributable package and notes that app-local deployment is possible but not recommended for servicing reasons.

In short: the docs do not provide a Q&A-level statement that renaming msvcp140.dll to a hash-suffixed filename is permitted. If you need a defensible licensing decision, get that confirmed through Microsoft licensing/support; if you need the safest documented deployment path, use the official VC Redistributable package or the redistributable DLLs as provided under the applicable license terms. Hope this helps clarify things. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guidance or provide feedback.

Thank you.

nhpokon 40 Reputation points

2026-08-24T04:47:11.95+00:00

Thank you for the detailed explanation. I understand that Microsoft Q&A can’t give a binding legal interpretation on whether a filename-only rename is permitted. The explanation of the supported deployment options and the recommendation to use the official VC++ Redistributable package or the redistributable DLLs as provided was very helpful. I’ll take the conservative approach and consider contacting Microsoft licensing/support for a definitive answer. Thanks again for your guidance.