vcruntime with a self-contained application

[samuel-lucas6]

How would you recommend bundling the Visual C++ Redistributable for Visual Studio 2015-2022 with a self-contained application so it's completely portable? I'm wondering if there's a better alternative to something like this.

Perhaps worth mentioning in the docs as well.

[ektrah]

Writing executable binaries to the file system (outside installers) is a security concern (which is why your code will probably fail if Environment.ProcessPath starts with C:\Program Files and the process is not running with administrator privileges). I would rule any such solution out.

I'm not sure if the Visual C++ Redistributable is even still needed on a naked Windows installation, since Windows 10 and later include Universal CRT and I believe the pre-compiled libsodium binaries are able to work with that. I've never tested that, though.

At the moment, my recommendation would be to deploy the self-contained application, see if it it works, and only install the official Redistributable if not.

[samuel-lucas6]

I would rule any such solution out.

Yeah, I'm not happy about it. I was wondering if there was some way of bundling it like the other DLLs.

I'm not sure if the Visual C++ Redistributable is even still needed on a naked Windows installation

I will try to test this in a VM at some point. I know it's needed in the Windows Sandbox. It's annoying for deployment.

[samuel-lucas6]

Doesn't seem to work on a clean Windows 10 VM. Get a DllNotFoundException like in the sandbox.

[ektrah]

I see. Thanks for checking!

I think there are now two ways for further investigation:

1. Is there a way to compile libsodium slightly differently so that it works with the Universal CRT that should be present on a clean Windows 10 VM.

2. Is there a way to bundle the Visual C++ runtime with the .NET application ("DLLs in the application local folder").

[ektrah]

I think it's up to the application to bundle the Visual C++ runtime, either in the form of .msi merge modules or in some other way. I don't think there is anything that NSec (or any other libsodium binding for .NET) should include to handle this. The most promising way forward is probably to investigate UCRT; any changes to libsodium for that would need to happen in the libsodium repository. I'll therefore close this issue. (Feel free to re-open if you disagree!)