Hot Reload

[Happypig375]

Is your feature request related to a problem? Please describe.

C# is getting Hot Reload for .NET 6. Will F# receive the same experience? Roslyn has had work done to support this. The F# compiler doesn't seem to have any equivalent work on this.

Describe the solution you'd like

F# can use hot reload just like C#.

Describe alternatives you've considered

Staying behind in terms of tooling again.

Additional context

If the issue is about:

• improving a compiler error message: No.
• improving/adjusting the parser: No.

Add any other context or screenshots about the feature request here.
dotnet/core#5510

[Happypig375]

https://devblogs.microsoft.com/dotnet/introducing-net-hot-reload/

F# is currently not supported in .NET 6 but we are planning to support in a future release based on customer feedback.

Of course F# is staying behind in terms of tooling again. 😞

[charlesroddie]

What's the current status if:

• You run a C# project that supports edit and continue/hot reload
• This depends on an F# project
• After making a change in the F# project, you build it.

Is hot reload able to support that currently? I.e. loading the updated assembly.

[cartermp]

It'll happen eventually here, but hot reload is a very new technology that is likely to undergo several changes well after .NET 6. We'll plug into it when it's more stable.

[KevinRansom]

@happypig, @charlesroddie --
what do you want hot reload to do for you? Just asking for a feature name is probably not going to get anything moving. We don't have plenty of other C# features also, and we don't plan on going down the VB route of moaning whenever we don't get some new C# feature.

[forki]

For me personally the biggest win is with projects that we start with "dotnet watch run". Usually those are expecto tests or asp.net core servers. If dotnet watch run would work like fable and keep a compiler in memory that only recompiles the stuff that is dependent on the files that I touched, then the dev cycle could speed up dramatically. I don't think we would need hot module replacement like webpack does - just restart the process like dotnet watch run would do right now. Kevin Ransom (msft) ***@***.***> schrieb am Di., 8. Juni 2021, 23:46:

…

@happypig <https://github.com/happypig>, @charlesroddie <https://github.com/charlesroddie> -- what do you want hot reload to do for you? Just asking for a feature name is probably not going to get anything moving. We don't have plenty of other C# features also, and we don't plan on going down the VB route of moaning whenever we don't get some new C# feature. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#11636 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAOANETHSOIUAQRKRF6SVLTR2FSPANCNFSM46EKO77A> .

[charlesroddie]

From the linked thread:

dotnet/core#5510 (comment) How fast developers can make code changes and see the resulting impact in their apps is directly proportional to how productive they can be.

Most important is a quick development loop when changing bits of UI (likely to be MAUI with WinUI as primary development platform). For non-UI code I don't need to run code very often, sometimes only once after finishing a work item to check that it works. But for UI code a lot of tweaks and adjustments are important and need to be visualized by running the code.

Hot reload would be perfect for this but does look like a very large task for F# to support Edit and Continue which it is based on.

A typical UI tweak doesn't affect the API of an assembly so reference assemblies will speed up the loop.

Hypothetically if it were possible, while running an application, to edit a dependent project, build it, and switch in the dll, it might capture most of the benefit of hot restart. But this may not be possible in dotnet?

[heronbpv]

Would support for generating files for FSI scripting, like the one provided by the F# Power Pack back in the day, be an alternative in this case? Together with script debugging, of course.
I can do it in VS 2015 with the plugin for something like winforms, for example. It's more clunky than have it done automatically, for sure, but also closer to home.

[albertwoo]

I am using blazor with fsharp. Hot reload will speed up the poductivity a lot.

[farlee2121]

This is a critical tooling enhancement for my usage of F#.

Is there some way I can contribute to move up the timeline?
(I don't currently have a great feel for the scope of work needed)

[vzarytovskii]

This is a critical tooling enhancement for my usage of F#.

Is there some way I can contribute to move up the timeline?
(I don't currently have a great feel for the scope of work needed)

I don't think we have a full understanding of what has to be done yet.

[farlee2121]

I decided to spelunk and get a better idea of what it takes to implement hot reload.

Full notes are in this gist https://gist.github.com/farlee2121/24915fb0518ad4ca6631bc33d0ff401c

Finds so far

• Dotnet CLI implementation looks like it'll also cover Visual Studio support
  • source: https://devblogs.microsoft.com/dotnet/introducing-net-hot-reload/
• Need to add a hot reload project capability to f# projects
  • example: Require individual languages opt-in to Hot Reload sdk#19608
• The change watching is done at the file level before language-specific considerations
  • source: https://github.com/dotnet/sdk/blob/baecd78dd60fc32f2cc942d3df6a520c28ac96ad/src/BuiltInTools/dotnet-watch/HotReloadDotNetWatcher.cs#L131
• Delta appliers appear to be be reusable
  • this should get us desktop, asp.net core, and web assembly support out of the box
  • here's one of the DeltaAppliers
• Diffs generators will need to be implemented for F#
  • The diff shape should be as defined by Microsoft.CodeAnalysis.ExternalAccess.Watch.Api.WatchHotReloadService.Update in order to reuse DeltaAppliers
  • We'll need to compute scope of recompilation and generate prartial updates for IL, pdbs, and metadata
• Hot reload depends on hard-coded services and file extensions
  • probably add our implementation to Microsoft.DotNet.Watcher.Tools.HotReload.cs because CompilationHandler is tied to Roslyn
  • WARN: This prevents modular deployment, and we may not want to ship the F# implementation to all users
• README for hot reload

Oustanding investigations

• TODO: Looking into F# partial compilation capabilities
• TODO: Look into support for solutions with projects in multiple languages
• TODO: understand where application state is preserved

[farlee2121]

A quick update. I made an experimental fork.

It's pretty basic so far

• Handles project changes
• Handles new files
  • There is a gotcha with VisualStudio. The build fails because the VS implicitly modifies the project file, but doesn't save it right away
• Rebuilds on any change to any .fs file

The running program will show changes, and much faster than the existing dotnet watch. The main issue is that debug artifacts are not updated with this strategy.

A more accurate description is that rebuilding tries to output both dlls and pdbs, but those resources are already in use by the debugger process.