Microsoft.Azure.Cosmos copies older vcruntime140 DLLs, creating risk of ABI breaks + crashes

[nsgomez]

We are continuously addressing and improving the SDK, if possible, make sure the problem persist in the latest SDK version.

Describe the bug
The Microsoft.Azure.Cosmos package includes build targets to copy msvcp140.dll, vcruntime140.dll, and vcruntime140_1.dll. This causes issues for .NET Core services where the Cosmos SDK causes a downgrade of the Visual C++ runtime compared to what the machine already has installed. This has caused an ABI break when using the latest compiler headers and can cause the service to crash.

To Reproduce
See microsoft/STL#4000 - opting into enabling the constexpr mutex constructor in Visual C++ in another mixed native/managed assembly will crash the .NET runtime if the Cosmos DB SDK is copying an older runtime.

See also microsoft/STL#4338:

There was also some wailing and gnashing of teeth from folks in Microsoft who were using current headers and old libraries - an unsupported scenario - who had to fix their broken builds/processes/pipelines.

MSFT internal: One#27929579 notes that the best solution is to stop copying old DLLs and let the system update them. We're trying to do this for my team's service but can't because of the Cosmos DB SDK.

Expected behavior
Referencing the Microsoft.Azure.Cosmos package does not copy old runtime redists. The SDK should assume the runtime is already installed and being updated, or at least have an option to disable this behavior.

Actual behavior
Microsoft.Azure.Cosmos copies old runtime redists.

Environment summary
SDK Version: 3.33.0
Windows Server 2022 x64

[ealsur]

@adityasa These DLLs are related to ServiceInterop. Do you know if they are still needed?

[adityasa]

@ealsur I don't know off the top of my head. IIRC, these binaries are also present in the cluster image. It's not clear to what degree does the dependency apply, since service interop is a fraction of backend code running in the cluster image.