search

dotnet / fsharp

The F# compiler, F# core library, F# language service, and F# tooling integration for Visual Studio
https://dotnet.microsoft.com/languages/fsharp
MIT License
3.94k stars 788 forks source link

FSI and FSC default to at most .NET Framework 4.6.1, missing .NET 4.6.2/4.7/4.7.1/4.7.2 #4946

Closed dsyme closed 5 years ago

dsyme commented 6 years ago
cartermp commented 6 years ago

@dsyme are the targeting packs for these installed on your machine?

dsyme commented 6 years ago

No they aren't you're right.

dsyme commented 6 years ago

Still we need to detect them to make F# Interactive pick them up, see PR https://github.com/Microsoft/visualfsharp/pull/4947

cartermp commented 6 years ago

Makes sense. Can you update the issue?

dsyme commented 6 years ago

Updated.

realvictorprm commented 6 years ago

(@dsyme there's a small typo in the title mising instead of missing)

cartermp commented 6 years ago

@dsyme Should this also be a consideration for the FSI/.NET Core plan (that I swear I'll encode in the RFC soon...)?

cartermp commented 6 years ago

@KevinRansom @dsyme we should get this worked out, at least for FSC, but January.

KevinRansom commented 6 years ago

@dsyme,

I am assuming you are discussing the behaviour of the command line tool, rather than the behaviour of the compiler under the tooling, specifically the behavior of referencing a framework assembly without specifying the path to the assembly being referenced.

For VS 2019 RTM will have a dependence on .NET 472 and so we will update FSI and FSC for the desktop to prefer net472, and fall back through the others.

However, developers should use NetSDK projects for the fsc compiler and nuget packages for Fsi dependencies. Relying on this hunting about resolution needs to be discouraged.

Kevin

dsyme commented 6 years ago

@kevinransom Yes, and thus also the default assemblies referenced (eg System, mscorlib) when you start fsi.exe

psantoro commented 6 years ago

My first attempt to use the --noframework flag was unsuccessful (issue #5964). I believe the documentation for the F# advanced compiler options leaves out some details, so here's my feedback.

The attached sample project targets .NET 4.7.2 and seems to work. It uses a makefile and is built with nmake on Windows. This sample may help others who are trying to use a version of .NET not yet included in FSC's built-in resolution logic. If time permits, I would appreciate it if someone can review it and let me know if I've missed anything.

In general, I believe this issue can be categorized as a mode error (see chapter 11 of BEHIND HUMAN ERROR 2nd Edition). In this case, the F# compiler (by default) is using a built-in mode to resolve the .NET assemblies to be used when the project is compiled/run, but fails to make this fact observable to the user.

Perhaps the F# compiler should output this information to stdout to make this fact observable, when the --nologo option is not used or when a new --verbose flag is used? This output could include the target .net version chosen and/or the full path of each implicitly used DLL. This information may prove useful for debugging build issues going forward.

As documented, the F# compiler --noframework flag runs the compiler in a different mode (i.e. FSC default CLI assemblies aren't used). It appears that in the --noframework mode the --lib flag is ignored for mscorlib.dll and FSharp.Core.dll. Given that these 2 DLLs are critical to the build process, this is understandable.

It is also unclear what the --simpleresolution flag actually does from the documentation. From my testing, this flag appears to support searching for references using the paths found via other references and those included in the --lib flag (instead of using the built-in MSBuild resolution). I'm guessing that it might not always be safe to use the --noframework flag without using the --simpleresolution flag. If so, then perhaps the compiler should throw a warning or error in this case?

hashset472.zip

Peter

KevinRansom commented 6 years ago

Yeah …. having the compiler search for references is always going to be environment dependent. Personally, I wouldn’t even try to make it work.

--noframework tells the compiler to use the references to mscorlib.dll and fsharp.core.dll passed on the command line. --simpleresolution tells the compiler to not hunt around for references and not to use msbuild resolution, but to use fully qualified references supplied on the command line.

Any hunting around resolution that happens after that is fallbacks that exist to ensure that FSI #r scenarios work.

For the compiler use msbuild and the netsdk, or legacy project stuff. For FSI, use nuget and fully qualified paths.

If you are using something other than msbuild, Do Not rely on the compiler to hunt around for dependencies specify them fully in your build system.

Sorry, but assembly resolution for framework assemblies is hard, platform dependent and whatever you have installed dependent. The easiest and least error prone is to rely on msbuild, at least for msbuild the important scenarios have been worked on over many years and made to work.

Kevin

From: psantoro notifications@github.com Sent: Monday, December 3, 2018 5:30 PM To: Microsoft/visualfsharp visualfsharp@noreply.github.com Cc: Kevin Ransom Kevin.Ransom@microsoft.com; Mention mention@noreply.github.com Subject: Re: [Microsoft/visualfsharp] FSI and FSC default to at most .NET Framework 4.6.1, missing .NET 4.6.2/4.7/4.7.1/4.7.2 (#4946)

My first attempt to use the --noframework flag was unsuccessful (issue #5964https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fvisualfsharp%2Fissues%2F5964&data=02%7C01%7CKevin.Ransom%40microsoft.com%7C6eecf3e4b18a4f8fd41c08d65988013e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636794838009471258&sdata=qFmCQjXw%2FABeKvjRVBsUbr5BFyIIKSuzf1on%2F26i30s%3D&reserved=0). I believe the documentation for the F# advanced compiler options leaves out some details, so here's my feedback.

The attached sample project targets .NET 4.7.2 and seems to work. It uses a makefile and is built with nmake on Windows. This sample may help others who are trying to use a version of .NET not yet included in FSC's built-in resolution logic. If time permits, I would appreciate it if someone can review it and let me know if I've missed anything.

In general, I believe this issue can be categorized as a mode error (see chapter 11 of BEHIND HUMAN ERROR 2nd Edition). In this case, the F# compiler (by default) is using a built-in mode to resolve the .NET assemblies to be used when the project is compiled/run, but fails to make this fact observable to the user.

Perhaps the F# compiler should output this information to stdout to make this fact observable, when the --nologo option is not used or when a new --verbose flag is used? This output could include the target .net version chosen and/or the full path of each implicitly used DLL. This information may prove useful for debugging build issues going forward.

As documented, the F# compiler --noframework flag runs the compiler in a different mode (i.e. FSC default CLI assemblies aren't used). It appears that in the --noframework mode the --lib flag for some DLLs (mscorlib.dll, FSharp.Core.dll) is ignored; as the only way I could get the F# compiler to resolve them was to use a relative or full path with the -r flag (i.e. a simple filename with the -r flag and use of --lib does not appear to work for these two DLLs). Given that these 2 DLLs are critical to the build process, this is understandable - but maybe more specific warnings could be added if simple filenames are used with the -r flag for these DLLs?

It is also unclear what the --simpleresolution flag actually does from the documentation. From my testing, this flag appears to support searching for references using the paths found via other references and those included in the --lib flag (instead of using the built-in MSBuild resolution). I'm guessing that it might not always be safe to use the --noframework flag without using the --simpleresolution flag. If so, then perhaps the compiler should throw a warning or error in this case?

hashset472.ziphttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fvisualfsharp%2Ffiles%2F2641929%2Fhashset472.zip&data=02%7C01%7CKevin.Ransom%40microsoft.com%7C6eecf3e4b18a4f8fd41c08d65988013e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636794838009481267&sdata=GNBxht79EtTcwOSnPg4AFiI3r6ABqCly%2FX5jYbdvgg0%3D&reserved=0

Peter

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fvisualfsharp%2Fissues%2F4946%23issuecomment-443935197&data=02%7C01%7CKevin.Ransom%40microsoft.com%7C6eecf3e4b18a4f8fd41c08d65988013e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636794838009491271&sdata=v%2FpVs8p0blmYNAaCYkKz%2BvxivaIHROk59BST1mltAW4%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAE76FtJCrq5OLuYl9iISJQ3DjhGhoj2Dks5u1dAWgaJpZM4UE8NP&data=02%7C01%7CKevin.Ransom%40microsoft.com%7C6eecf3e4b18a4f8fd41c08d65988013e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636794838009491271&sdata=Vl7egrhWnhkQVrfhlXhAUSkyb%2BrhrEuCc5HImYec8SE%3D&reserved=0.