remove support for --noframework from fsi #15362
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
--noframework tells the compiler to not implicitly find and load framework assemblies.
This ability is essential for the compiler because, there are multiple versions of the dotnet framework, reference assemblies and runtime assemblies. The compiler needs to be able to specifically identify which Apis are supported on the intended framework, so having it guess which assemblies to load based on incomplete information is likely to be dependent on what is installed on the target machine. It is intended that when this switch is specified that the developer specifies the exact and complete closure of assemblies required by the compilation using the -r: path to assembly command line option. Msbuild is the tool we use to generate these, on the desktop this closure will likely be a half a dozen or more assembly paths. Targetting coreclr assemblies this may be 60 or more assemblies.
The option doesn't make much sense when running a script or directly interaction with Fsi. The reason is that on the coreclr the number of specific assemblies to reference is huge, and thus very hard to type. Even on the desktop it is not that easy. Additionally the implementation assemblies loaded are specified by the coreclr host when it starts fsi.exe
For these reasons, I am just turning off the switch, because the switch was originally specifiable, I am leaving it valid to specify, but it will make no changes when executing fsi or dotnet fsi.