Add single-file app's dir to NATIVE_DLL_SEARCH_DIRECTORIES #42876
Conversation
|
Tagging subscribers to this area: @agocke |
|
I think the logic should be:
This should specifically cover the 3.1 backward compat mode (I know it works today on Windows, but it won't work on Linux ). We obviously need tests for this - we can start with validating the content of the |
What is broken with 3.1 compat mode on Linux for this? It should (with the fix for actually extracting) be able to search for native libraries based on the managed assembly's path? |
|
You're right that it will basically work - but as you pointed out - the design called for setting the extraction path as one of the native search directories - which this should fix. There are still potential scenarios (plugins) where not setting it will break the app (mostly on Linux), but I agree that they're not that common. |
|
I removed |
src/installer/tests/Microsoft.NET.HostModel.Tests/AppHost.Bundle.Tests/SingleFileApiTests.cs
Outdated
Show resolved
Hide resolved
| public void AppContext_Native_Search_Dirs_Contains_Bundle_And_Extraction_Dirs() | ||
| { | ||
| var fixture = sharedTestState.TestFixture.Copy(); | ||
| Bundler bundler = BundleHelper.BundleApp(fixture, out string singleFile, BundleOptions.BundleNativeBinaries); |
There was a problem hiding this comment.
Do we need to make sure the bundle actually has something to extract so that it creates/adds the extraction directory? By default, we won't have anything to extract on Linux, right?
src/installer/tests/Microsoft.NET.HostModel.Tests/AppHost.Bundle.Tests/SingleFileApiTests.cs
Show resolved
Hide resolved
src/installer/tests/Microsoft.NET.HostModel.Tests/AppHost.Bundle.Tests/SingleFileApiTests.cs
Show resolved
Hide resolved
src/installer/tests/Microsoft.NET.HostModel.Tests/AppHost.Bundle.Tests/SingleFileApiTests.cs
Show resolved
Hide resolved
|
@mateoatr I don't think these changes are strictly necessary, they're more test hygiene suggestions. If you think it would be faster to deal with these separately, that's fine. We can merge this change, and take the modifications in another PR. |
|
@agocke I had some issues testing locally, but I just pushed your suggestions. I think we can merge after all tests run in the CI. |
|
Yeah, I've been trying to work on stuff locally and mostly got stuff to work by building everything, then runnign the apphost test by doing |
| .And.HaveStdOutContaining("ExecutingAssembly.Location: " + extractionDir) // Should point to the app's dll | ||
| .And.HaveStdOutContaining("AppContext.BaseDirectory: " + extractionDir) // Should point to the extraction directory | ||
| // In extraction mode, we should have both dirs | ||
| .And.HaveStdOutMatching($"NATIVE_DLL_SEARCH_DIRECTORIES: .*{extractionDir}.*{bundleDir}"); |
There was a problem hiding this comment.
Huh, I assume the Matching is turning this into a regex, meaning that the \s now need to be escaped on Windows?
|
Moving us back to the previous commit, since that passed tests, so we can get this in today |
) Add two directories to NATIVE_DLL_SEARCH_DIRECTORIES to single-file bundles: 1. The bundle exe directory 2. If the bundle extracts any files, the extraction directory Fixes dotnet#42772 (cherry picked from commit 0403018)
ghost
locked as resolved and limited conversation to collaborators
Fixes #42772. I took the easy path here - whenever the app is single-file, add the exe's dir to
NATIVE_DLL_SEARCH_DIRECTORIES. Additionally, if the user sets-p:IncludeNativeLibrariesForSelfExtract=true, add the extraction path to the search directories.