Fsharp: Consider supporting #r: "frameworkreference:"

[cartermp]

In F# 5, we'll have `#r "nuget:...". However, there are some first-party frameworks where this won't work:

• ASP.NET Core
• Windows Desktop

ASP.NET Core 2.x used is just a few NuGet packages, so it's possible to write an F# script that uses that to do some webby stuff. But if you want you use the latest ASP.NET Core, you need to magically know the closure of every assembly in the ASP.NET Core framework reference, reference those, and then use it. Horrible experience.

Also, the old school F# scripts that used to launch WinForms currently can't do this with .NET Core (on Windows). This is because WinForms and WPF both use the Windows Desktop framework reference, and an additional MSBuild property to tell the build system which additional references to pull in (UseWinForms and UseWPF). Both can be specified at the same time. We may want to have a think about what it would mean to support these.

tagging his majest, @KevinRansom

[KevinRansom]

Agreed, I wonder what it would look like.

[cartermp]

Perhaps:

#r "frameworkreference: aspnet"

#r "frameworkreference: windowsdesktop, usewinforms=true
#r "frameworkreference: windowsdesktop, usewpf=true
#r "frameworkreference: windowsdesktop, usewinforms=true, usewpf=true

?

[KevinRansom]

So, if I understand the request it is to handle the dotnet framework packs that are distributed with the dotnet sdk.
Here:

It feels like in order for net5.0 apps to work dotnet build already knows how to do this, so perhaps it's merely a simple extension to #r "nuget: ..."

for example:

r "nuget: Microsoft.AspNetCore.App.Ref, 5.0.0-preview.3.20214.2"

r "nuget: Microsoft.WindowsDesktop.App.Ref, 5.0.0-preview.3.20214.2"

or perhaps:

r "nuget: pack=Microsoft.WindowsDesktop.App.Ref, version=5.0.0-preview.3.20214.2"

And we use this to set the tfm for the build to the required tfm, not sure how the version maps yet. but I expect there are knobs.

What do you think?

[Krzysztof-Cieslak]

It looks like this in the project file: https://github.com/SaturnFramework/Saturn/blob/master/src/Saturn/Saturn.fsproj#L28

So maybe #r "nuget: framework=Microsoft.AspNetCore.App" ?

edited: kcr, adding snippet
<snip> <ItemGroup Condition=" '$(TargetFramework)' == 'netcoreapp3.1' "> <FrameworkReference Include="Microsoft.AspNetCore.App" /> </ItemGroup> </snip>

[baronfel]

FWIW @Krzysztof-Cieslak, you only need that framework reference because the SDK in the project file isn't set to the SDK for aspnetcore: "Microsoft.NET.Sdk.Web". If you did that the FrameworkReference would become redundant.

[baronfel]

Similarly for the Windows Desktop stuff, if you use the matching SDK some set of the framework references are handled for you (based on those msbuild properties mentioned), so I wonder how much of this request is around framework references specifically, vs importing and using SDKs?

[KevinRansom]

@baronfel , so it could also look like?
````

````

So #r "nuget: sdk=Microsoft.AspNetCore.App"
could also be in the frame?

I think I like @Krzysztof-Cieslak 's suggestion it's a bit crisper, and @cartermp has suggested there may be several, frameworkreference is a bit easier to read in the project file.

[baronfel]

@KevinRansom

<Project Sdk="Microsoft.NET.Sdk.Web">
</Project>

Of course it would be too clear if the names matched up.

[KevinRansom]

@baronfel , never underestimate our ability to evade clarity :-)

[cartermp]

Yeah, having the names match up with the SDK names would be ideal. Is that something we'd considering keeping track of in the dependency manager? I highly doubt these names will change over time, since that would also mean that all visual studio tooling and SDK stuff would have to change as well.

[theundergroundsorcerer]

@cartermp
I am not sure whether it is related, but wrapping Forms calls into a dll, and then trying to use the dll from a script is not possible either. (There is no problem with other modules defined in the same dll).