A full F# project (Console Application + F# Library) has no problems propagating changes so that they're visible in intellisense without executing a manual build after changes. Neither VS 2015 (with or without power tools) or VS 2017 seem to support seeing intellisense changes in a C# project referencing an F# project without doing a manual build.
Reproduction:
type Test = A | B | C in the F# library.Test objects:var a = Test.A;
var b = Test.B;
var c = Test.C;
type Test = A | B. Save all files.Expected:
The F# project is building in the background (as is evident of full intellisense support of a 100% F# project with project references). It makes sense that other .NET languages should be able to see the results of the background build via intellisense. Maybe this is unreasonable because of the current state of some inner workings of VS/Intellisense, but it is definitely frustrating from a user standpoint. As someone coming from 100% C# wishing to port our back-end to F#, this has been a major pain point.
Workaround:
I have recently started using this extension which gives me the behavior I want on save:
https://marketplace.visualstudio.com/items?itemName=pragmatrix.BuildOnSave
I was a little worried that it would be extremely slow on a full blown solution with WPF + Xamarin (Android/iOS) + libraries + NuGet, but it hasn't proven to be much of an issue so far.
@Pilchie @dsyme this is about the legacy F# project system interacting with C# projects in the native project system. I don't think the "see differences without a rebuild" behavior has ever worked. Would that be "by design" in the sense that they shouldn't be able to talk to each other like that? If so, then I think the correct resolution is to migrate F# projects over to CPS.
That wouldn't help. The problem is that F# only reads metadata from built C# projects, and the same is true vice versa.
C# and VB work because Roslyn has APIs to EmitMetadataOnly and the IDE does that to a memory stream whenever there are P2P refs.
I don't think the "see differences without a rebuild" behavior has ever worked.
That's correct
Would that be "by design" in the sense that they shouldn't be able to talk to each other like that?
It would be "Feature improvement"
If so, then I think the correct resolution is to migrate F# projects over to CPS.
Agreed that wouldn't solve the problem, but it would be a good first step towards solving it
How hard would it be to implement an option in the compiler to only emit metadata, given its current state? I am considering using this as an opportunity to contribute and put together a pull request if this isn't too complex of an addition 馃
@SirUppyPancakes Very complicated is the answer. We're currently working on changes to how the F# language service emits and reads F# metadata, and something like that could potentially be adapted to work similar to how C# and VB do. But it's incredibly complex stuff and we're taking a long time of it on our end just so that we don't regress a large number of scenarios.
Makes sense, thanks for the quick reply!
I'm observing something similar...
My "Coordinates" type that's declared in my F# library isn't recognized in my C# library:
I have performed the following steps:
After the above steps, my C# project still doesn't pickup the latest type declarations in my F# project.

@bizmonger What you're seeing is by design.
type Coordinate = Latitude * Longitude
Isn't a type, it's a type abbreviation. See this section in the docs on avoiding the use of type abbreviations when modeling a domain: https://docs.microsoft.com/en-us/dotnet/fsharp/style-guide/conventions#avoid-using-type-abbreviations-to-represent-your-domain
Most helpful comment
That wouldn't help. The problem is that F# only reads metadata from built C# projects, and the same is true vice versa.
C# and VB work because Roslyn has APIs to EmitMetadataOnly and the IDE does that to a memory stream whenever there are P2P refs.