From: Steve Harter Date: Tue, 7 Nov 2017 20:40:53 +0000 (-0600) Subject: Add proposed 2.1 multiple framework support X-Git-Tag: submit/tizen/20210909.063632~11032^2~1055 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=70ba22eb74ce3951449d00e3b3ec9662d9b57073;p=platform%2Fupstream%2Fdotnet%2Fruntime.git Add proposed 2.1 multiple framework support Commit migrated from https://github.com/dotnet/core-setup/commit/e22aa76ee36821d0f8a2d12bad6652cc7f603edb --- diff --git a/docs/installer/design-docs/multilevel-sharedfx-lookup.md b/docs/installer/design-docs/multilevel-sharedfx-lookup.md index 40a47a7..ed59c05 100644 --- a/docs/installer/design-docs/multilevel-sharedfx-lookup.md +++ b/docs/installer/design-docs/multilevel-sharedfx-lookup.md @@ -65,6 +65,46 @@ Hostfxr must then locate the hostpolicy.dll file: The hostpolicy is then loaded into memory and executed. +### Proposed hostfxr changes for 2.1 +There can only be one framework in 2.0. That framework is located in the app's runtimeconfig.json: +```javascript +{ + "runtimeOptions": { + "tfm": "netcoreapp2.0", + "framework": { + "name": "Microsoft.NETCore.App", + "version": "2.0.0" + } + } +} +``` + +From the framework's `name` and `version` the appropriate framework location is found as explained earlier. + +In order for other frameworks (or platforms such as ASP.NET) to get the same benefits of roll-forward and self-containment for serviceability, 2.1 will support multiple frameworks. + +For 2.1, a given framework can only depend upon another single framework. An app can still only depend upon a single framework as well. Thus it repesents a "vertical" hierarchy. It is possible to allow additional frameworks in a "horizontal" manner, but that is out of scope for 2.1. + +Each framework has its own roll-forward semantics. This means ASP.NET can roll-forward independently of NETCore.App even though ASP.NET depends upon the NETCore.App framework. + +NETCore.App in 2.0 has its own deps.json file in its own folder that lists its assemblies. In 2.1, other frameworks will also have their own deps.jon. In addition, each framework has an optional runtimeconfig.json that describes its framework dependency as well as other settings that exist today (applyPatches, preReleaseRollForward, rollForwardOnNoCandidateFx). If the runtimeconfig.json file does not exist, or does not have a value for a setting, it uses the value from the higher-level runtimeconfig.json. + +For example, an MVC app's runtimeconfig.json would contain (actual framework names TBD): +```javascript +"framework": { + "name": "Microsoft.AspNetCore.All", + "version": "2.1.0" + } +``` +and Microsoft.AspNetCore.All's runtimeconfig.json would contain: +```javascript +"framework": { + "name": "Microsoft.NETCore.App", + "version": "2.1.0" + } +``` +and Microsoft.NETCore.App would not have a runtimeconfig.json because it doesn't have any framework dependency or need to change other settings. + ## Hostpolicy Hostpolicy is in charge of looking for all dependencies files required for the application. That includes the coreclr.dll file which is necessary to run it. @@ -78,6 +118,15 @@ Both files carry the filenames for dependencies that must be found. They can be At last, the coreclr is loaded into memory and called to run the application. +### Proposed hostpolicy changes for 2.1 +For 2.0, there are several probing paths that are used to find the dependencies. These paths follow a certain order and the first assembly found wins and that location will be passed to the coreclr. For example, the local app location has priority over the shared framework locations and if the same assembly exists in both locations, the coreclr will end up using the local app's copy of that assembly. + +These semantics will be unchanged for 2.1 except when a roll-forward is performed at a non-patch version (meaning a change to the major or minor version). For these cases, the highest assembly version wins. This is necessary in run-time scenarios to prevent assembly load exceptions which occur when an assembly is referencing a higher version of another assembly, but a lower version is actually found. + +There will be some checks added to hostpolicy to catch these conflicts during development scenarios, but since this conflict scenario should only occur during roll-forward, and on a version of the framework likely not even released yet during development, these checks will focus on correctness of the currently targeted framework. This ennsures that any duplicate versions higher up the framework stack have a newer assembly version than the copies of that assembly in the lower level frameworks. + +This situation of having assembly conflicts (or duplicates) is more likely to occur when there are multiple frameworks (as convered in hostfxr's proposed changes for 2.1), so it is important to address in the 2.1 timeframe. + ## Global locations In addition to searching the executable directory, the global .NET location is also searched. The global folders may vary depending on the running operational system. They are defined as follows: