Azure / azure-cosmos-dotnet-v3

.NET SDK for Azure Cosmos DB for the core SQL API
MIT License
723 stars 477 forks source link

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

Open nsgomez opened 1 month ago

nsgomez commented 1 month ago

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 https://github.com/microsoft/STL/pull/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 https://github.com/microsoft/STL/issues/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 commented 1 month ago

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

adityasa commented 3 weeks ago

@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.