Skip to content

Conversation

@KevinRansom
Copy link
Contributor

--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.

@KevinRansom KevinRansom requested a review from a team as a code owner June 9, 2023 20:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

4 participants