Closed joshua-software-dev closed 1 year ago
Good find, but what would the benefit be of removing msquic from WINEDLLOVERRIDES
and instead do it this way?
A smaller amount of necessary configuration seems like it would be better. The improvements found in the discord related to maybe not needing to install WinPcap_4_1_3.exe
through more clever file manipulation plus this push IINACT closer to not needing to understand as much to get it working. Less points of potential failure.
Other than that, its not faster or more clever or more maintainable or anything fancy. Just one less default dialed to a less than ideal setting. If you keep your existing WINEDLLOVERRIDES
, it doesn't break that either. That setting would just be telling wine to do something that should never come up anymore with this fix, harmlessly.
Good point. Kinda wish that the Winpcap stuff would also eliminate the need of having to override wpcap, but that's OT.
Thanks for this!
As per the following issues: https://github.com/dotnet/runtime/issues/74629 https://github.com/dotnet/runtime/issues/77420 https://github.com/dotnet/runtime/issues/82316
HttpClient (and other, older dotnet http options that depend on it) will load the msquic native library even if its not in use. This is fine as long as the native library doesn't crash on loading, which it unfortunately does on wine. There is currently no way to disable Quic specifically in order to work around this (although an option is being discussed for addition in .NET 8, see above issues). However, if HTTP/3 is disabled altogether with the environment variable:
DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP3SUPPORT
(See here)it does in fact prevent the msquic library from loading. This lets us remove
msquic
fromWINEDLLOVERRIDES="msquic=\,mscoree=n\,b\;wpcap=n"
and load successfully. The necessary network requests from FetchDependencies and IINACT work correctly in my testing, as none of the links fetched by IINACT or any of its libraries appear to require HTTP/3 support.