In-memory cross-project reference not working for project using a generative type provider

[jkone27]

When I use VS Build has 0 errors, but VS ide says there is errors.. this repo should allow to reproduce https://github.com/jkone27/test-broken

Workaround

Tools -> Options -> Text Editor -> F# -> Performance -> Turn off "Enable in-memory cross project references"

Details

I am on win10 and vs2019 (and vs2020 also affected)

e..g in another repo

[dsyme]

I can confirm this is a bug (haven't been able to check with main as yet, only with 16.10.3)

It goes away when you turn off in-memory cross project references

It is something to do with in-memory reference to a project using type providers

Workaround: Tools -> Options -> Text Editor -> F# -> Performance -> Turn off "Enable in-memory cross project references"

[dsyme]

@jkone27 Did you only experience this with repos that involve the Swagger type provider? If you have any other repros please include them

[dsyme]

@TIHan I'm recalling the details now. In brief, in-memory cross-project references simply don't work for projects involving generative type providers. However they should be implicitly disabled, that's what this PR was about: #3236

I suspect this implicit disablement is no longer functioning. The relevant code is still there:

                        if tcState.CreatesGeneratedProvidedTypes || hasTypeProviderAssemblyAttrib then
                            None
                        else
                            Some  (RawFSharpAssemblyDataBackedByLanguageService (tcConfig, tcGlobals, generatedCcu, outfile, topAttrs, assemblyName, ilAssemRef) :> IRawFSharpAssemblyData)

Perhaps if this kicks in the project assembly reference is now being completely dropped on the floor.

I'll look into it and debug further

[dsyme]

This looks like the problem:

        // If we have a project reference but did not get any valid contents,
        //     just return None and do not attempt to read elsewhere.
        if contentsOpt.IsNone && r.ProjectReference.IsSome then
            return None
        else

It is valid to get None in this case, and we should revert to the on-disk DLL if it exists, as a known limitation of the tooling.

Introduced here: #11485

I'll work on a fix and review why the testing added here: https://github.com/dotnet/fsharp/pull/3236/files#diff-07f76d461e78df1feb8cfc153fac5455336aba8964f51656905c041187a4fefdR777 didn't prevent this regression

[dsyme]

Fixed by #11791