-
Notifications
You must be signed in to change notification settings - Fork 4.8k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Extract bundled files when IncludeAllContentForSelfExtract is set (#4…
…2435) * Extract bundled files when IncludeAllContentForSelfExtract is set * Don't pass bundle probe to the runtime for netcoreapp3 compat mode * Bundle probe should not report extracted files This also means we can still pass bundle probe to the runtime even in full-extract case as all files will be marked as extracted in that situation (so the probe should return false all the time). This might be benefitial as the runtime will still "know" it's single-file (we don't really use that knowledge today though). Improve the test to actually validate locally built binaries and add validation of TPA and framework assembly loading. * CodeBaseThrows should fail * Normalize app base path * Search for CoreLib in TPA * PR feedback * Fix bundle tests to actually test single-file bundles The tests were basically running everything using apphost.exe - the reason the tests worked is basically a weird coincidence (the bundle was always self-contained so it had everything managed in it and all the native dlls were beside the .exe) - so from host's point of view this looked like a self-contained app - and then hostpolicy/hostfxr noticed it's also a bundle and treated it as such. This change introduces new test baseclass to reduce duplication and standardizes the tests to mostly use self-contained publish then bundled with singlefilehost.exe. Currently they do leave hostpolicy.dll and hostfxr.dll next to the exe (they're written in .deps.json so they must exist on disk) but at runtime they won't be used since the singlefilehost.exe has them bundled in itself. * Don't use Microsoft.NETCore.App.Internal package From 3.0+, Microsoft.NETCore.App just chains in the appropriate runtime packs. The .Internal package was necessary for tests to use when we were building with a older SDK, but targeting 3.0+. We should be able to get rid of the workaround now. This actually causes problems with the full extraction single-file mode because pre-5.0 and in the .Internal package, System.Private.CoreLib.dll was not listed as a runtime assembly (only under native). As a result, it would not end up in the TPA for a single-file bundle. * AppWithSubDirs: add back RuntimeIdentifier, don't use .Internal package The test assets are all restored - passing in TestTargetRid - before the test runs. Since we do a rid-specific publish later, it needs to be restored with the approriate rid. Stop using .Internal package. This resulted in host binaries getting published even for framework-dependent publishes. * Rework the single-file API tests for better coverage The tests now validate behavior of all of the interesting APIs in both single-file and backcompat mode. Added the AppContext.BaseDirectory to the tests. * Fix the reported path to .deps.json for back compat mode The path must point to the extraction folder and not use the "fake" in-bundle path. * Fix a test bug on Linux Actually we should be using path separator char in the APP_CONTEXT_DEPS_FILES, but that's something we won't be able to change really (too much chance of breaking something without too much value). Co-authored-by: vitek-karas <[email protected]> Co-authored-by: Elinor Fung <[email protected]>
- Loading branch information
1 parent
1c4910f
commit 0be66cb
Showing
29 changed files
with
599 additions
and
350 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.