News
F# Now Targets .NET Core Projects in Visual Studio
Microsoft's F# functional programming language now lets Visual Studio coders target .NET Core and .NET Standard projects.
That functionality is found in the latest preview release of the flagship IDE, Visual Studio 2017 15.5 Preview 4. While other previews have included the beginnings of F# support for .NET Core and .NET Standard projects, some important work items were just finished off in the latest preview, prompting Microsoft's announcement.
F# support is now built in to any Visual Studio projects based on the .NET Core SDK, including .NET Core, .NET Standard and .NET Framework projects. Now, in Visual Studio, .NET Core workloads, ASP.NET workloads and Azure workloads all feature default F# support.
In August, Microsoft released .NET Core 2.0 -- an open source, modular implementation of .NET -- and .NET Standard 2.0, which provides a common set of APIs that all .NET-based projects must implement for consistent API usage.
Since then, various Microsoft and third-party offerings have been catching up to support the initiatives, with F# among the latest.
[Click on image for larger view.] F# Support by Default (source: Microsoft).
F# developers who install the aforementioned workloads can now use the File | New Project menu to create new projects based on .NET Core and .NET Standard, though as of now support is limited to console apps, libraries and unit test projects.
In a blog post, Microsoft outlined some of the new features associated with the updated project support:
- Project files are significantly smaller, often by an order of magnitude.
- Project files are editable without having to unload the project.
- Coders can edit a project file (for example, adding a package) and when it's saved, the project system will automatically react to those changes (such as restoring an added package).
- NuGet dependencies, the SDK reference and project-to-project references are unified under the Dependencies node.
For the F#/.NET Core development roadmap going forward, Microsoft listed these issues remaining to be tackled:
- After creating a new project-to-project reference, the Error List in Visual Studio can show errors, even though developers get IntelliSense and their projects build. Developers can close/reopen documents for the errors to go away.
- Solution Explorer does not show the compilation order of files after developers first add them and move them in the project file. If developers reload a project, ordering will be shown correctly.
- Folder support is limited -- all folders are rendered above files in the root directory of a project. Microsoft will work out a design on how to handle this gracefully with file ordering in mind.
- C# libraries must first be built before their symbols are visible in F# projects.
- F# and ASP.NET Core templates are not yet available in the File | New project dialog.
- Microsoft will continue improving its cross-platform debugging support, specifically in Portable PDB generation.
- Performance of solution loading and cross-project IDE features in large .NET Core/.NET Standard solutions is still a place where major investments are being made by the team that owns the underlying project system F# uses for these project types. F# will benefit from all of these investments.
- Type Provider support for .NET Core is arriving towards a design that will enable quality support on .NET Standard and .NET Core. This redesign will involve changes to Type Provider libraries.
- Microsoft will soon begin work on enabling F# Interactive for .NET Core. This will be nontrivial work, so there's no estimated date of completion yet.
- There are no Visual Studio templates for F# Azure Functions yet. The F#/.NET team is going to work with the Azure Functions team to ensure that F# templates for different Function types will be in a forthcoming release.
"Finally, we are laying the groundwork for a long-term effort of migrating all F# projects to the new project system that .NET Core and .NET Standard projects use," Microsoft's Phillip Carter said in the blog post. "This will enable us to retire our current, F#-specific project system that .NET Framework projects use today. We'll first do this by 'dogfooding' our own codebase.
"There is no timeline for when this will happen, as it is a long-term effort, but it is a major goal of ours because it enables us to hand off project system concerns to experts in that space so that we can focus on the F# compiler and F# tooling."
Microsoft's repository for the open source F# language compiler, library and Visual F# tools can be found on GitHub.
About the Author
David Ramel is an editor and writer at Converge 360.