Does F# support ProduceReferenceAssembly

[xperiandri]

I use F# in Xamarin.Forms and discovered ProduceReferenceAssembly element in C# template of a common project.
So I wonder if this feature works in F#

[abelbraaksma]

That would be either /refonly or /refout as available for the C# compiler. Checking this: https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/compiler-options suggests that fsc.exe does not support it. Don't know if there's a workaround.

[cartermp]

The compiler doesn't support producing or consuming reference assemblies, no. This is something we'd like to do in the long-term since it can very positively affect memory consumption in IDEs. But it's not on the immediate roadmap yet.

[KevinRansom]

@xperiandri,
We consume ref assemblies fine, they are after all just assemblies. However, we don't produce them yet. It's in the long term plans, but we haven't got around to it yet. (By plans ... I mean, we mostly want to do it, it's not costed, scheduled or even designed.)

[charlesroddie]

This has large benefits:

• When compiling in msbuild, if project A is changed in a way that does not change its public API, projects dependent on A do not need to be rebuilt. The msbuild implementation described here: Support reference assemblies in build flows msbuild#1986. These changes are very common and going from O(n) to O(1) compilation time, where n is the number of projects, is a large benefit. (Rider and ReSharper builds have a different method to achieve the same outcome.)
• I believe (ok, I guess) that when an F# dll is read when referenced in another F# project, everything gets put in memory (including private/internal members, local functions). With a reference assembly, this waste wouldn't happen.

[charlesroddie]

Some additional discussion here: #8044 (comment)

It's worth testing whether https://github.com/ImperialPlugins/ReferenceAssemblyGenerator or https://github.com/JetBrains/Refasmer can preserve enough F# metadata for the resulting assembly to be understood by dependent F# projects.

[charlesroddie]

Copied from other thread since reference assemblies was considered separate from incremental recompilation of projects:

@smoothdeveloper In large dotnet projects, tools like Resharper or Rider already support incremental recompilation at solution/project level, shaving off a lot of time spent on building the solution, even when a project depended upon is changed, it won't recompile the depending projects unless there is top level API surface change.

@0x53A Roslyn/MsBuild added support for reference assemblies, would be great if fsc also supported this. Here is a good writeup from the MsBuild side: dotnet/project-system#2254 This is not directly related to the incremental build of a single assembly, but having this would enable to skip a lot of redundant recompilations.

@cartermp Reference assembly support is another good (also challenging) thing to add. Another benefit is a significant reduction in memory usage - for very large projects it could be upwards of 10% or less.

@TIHan Also, regarding reference assemblies: We will gain nothing when it comes to F#-to-F# referencing in tooling since we do not even build assembly data anyway. Our "reference assembly" in this case is the signature metadata. But, if we were to have better integration with C#/VB projects, it would be nice.

@TIHan I believe this last comment assumes that in-memory cross-project references is enabled. I don't think that's a good assumption given the poor performance of in-memory cross-project references when there are many projects. Maybe with a good incremental compiler the need for reference assemblies reduces - although at some point you will have to build!

[KevinRansom]

Closing: due to this thread is a dupe of this older thread: #3066 ,