Object Browser is not populated with assemblies refernced by fsproj

[xperiandri]

Object Browser tool window of Visual Studio is not populated with assemblies referenced by F# projects

Repro steps

1. Create new F# .NET Core project
2. Install any NuGet package
3. Open Object Browser
4. See that it is empty

Expected behavior

Object Browser tool window is populated with all the assemblies referenced by F# projects

Actual behavior

Object Browser tool window is empty

Related information

• Windows 10 Pro 10.0.16275.1000 Eng
• Visual F# tools 15.4.1.17082301
• .NET Core 2.0 RTM
• Visual Studio Enterprise 15.3.2
• Important

[dsyme]

@Pilchie Any idea what we need to implement to get the Object Browser to light up? Does anyone use this much in C#?

[cartermp]

Note that it is also empty for .NET Framework 4.7-based F# projects, so this isn't specific to .NET Core.

[xperiandri]

Well in full .NET Visual Studio displays F# projects from solution as external assemblies.
So that F12 from C# project to F# type worked as from metadata.

I hope this will finally work in some update of VS 2017, will it?

[xperiandri]

@cartermp, so when will this finally be implemented?
It is extremely annoying to not be able to look into referenced libraries!
I installed some NuGet. I want to look at API that are not displayed to me because if F# nature when coding. And I can't see them because they do not appear in this window 😓
It is very frustrating coding experience...

[cartermp]

This is a feature request and not a part of our plans around:

• .NET Core IDE bringup
• .NET Core platform support (test type providers more, enable FSI)
• Critical IDE or compiler work
• Infrastructure bringup

Thus there is no timeline. We may get it it, but there is no guarantee. We certainly welcome a pull request, though.

[xperiandri]

If someone can explain what approximately implement and where I can handle that.
I modified a few simple VSIX's to extend them but I have no idea what to do to implement this..

[dsyme]

@xperiandri In the context of the old project system I had thought it was a matter of implementing IVsSimpleLibrary2, see https://msdn.microsoft.com/en-us/library/bb165783.aspx.

In the context of the new project system https://github.com/dotnet/project-system/ the answer may be different however, and I don't understand why the new project system wouldn't at least be showing F# references as external assemblies. Surprisingly the new project system doesn't seem to implement IVsLibrary, IVsLibraryMgr, IVsSimpleLibrary2 or any such interfaces based on a quick search. I must however be missing something.

cc @srivatsn @Pilchie @davkean

[dsyme]

@xperiandri There is an implementation of IVsLibrary in Roslyn , which may be related https://github.com/dotnet/roslyn/blob/614299ff83da9959fa07131c6d0ffbc58873b6ae/src/VisualStudio/Core/Def/Implementation/Library/AbstractLibraryManager_IVsLibrary.cs#L9

https://github.com/dotnet/roslyn/tree/614299ff83da9959fa07131c6d0ffbc58873b6ae/src/VisualStudio/Core/Def/Implementation/Library/ObjectBrowser

I don't know what it would mean to light up this functionality for F#. It may be quite simple (especially if similar functionality has been lit up for TypeScript, which builds its VS support on the same code), but I think we need help from the Roslyn people to be given a rough guide.

[xperiandri]

@dsyme where can I get Guids.CSharpLibraryId for F#?

[xperiandri]

@Pilchie __SymbolToolLanguage does not have F# option

[xperiandri]

Any updates about this? How far is it in the backlog?

[rent-a-developer]

This is really unfortunate.
F# is such a wonderful and powerful language, but the tooling support for it is very limited.
At the moment writing F# code in Visual Studio often feels a bit like writing F# code in notepad.

I really doubt F# will gain much traction unless tooling support is greatly improved.
It feels like Microsoft is not really committed to F#. :-(

Which is such a shame, because, again, F# is such a wonderful language.

[smoothdeveloper]

@rent-a-developer, is the object browser lacking knowledge of F# assemblies the reason for your feedback?

Do you encounter times where writing other language than F# code in Visual Studio also feels a bit like notepad or is it specific to F#? and would you mind reporting specific issues about it?

Regarding doubts of F# gaining traction, it doesn't rely solely on Visual Studio tooling, but as I have been using it to write F#, I feel it has gained attention from Microsoft, over the years.

What you express feels like what I was hearing back then, and I am not sure the arguments about F# gaining traction, related to tooling, hold as much weight as they did (when there was no refactor support, and very basic navigation only).

@rent-a-developer, regarding object browser, can you adjust by using ILSpy or similar in meantime for similar needs? ILSpy shows a treeview which is pretty similar.

Also, do you have specific stance as to if the object browser should propose another representation, specific to F# (to show modules as such, etc.) or just the "how it looks at CLI API surface level" is what you'd like?

Thanks.

[xperiandri]

Full F# semantics would be nice. Along with that same semantics in Solution Explorer file nodes.
However basic .NET stuff support would be good to start with.

[xperiandri]

But my issue was that Object Browser does not work at all if you don't have a single C#/F# project in your solution. And for F# projects no dependencies are displayed there.
Open F# file, then Object Browser -> empty.
Open C# file, then Object Browser -> only C# dependencies.

[xperiandri]

and would you mind reporting specific issues about it?

#11787

[rent-a-developer]

@smoothdeveloper

@rent-a-developer, is the object browser lacking knowledge of F# assemblies the reason for your feedback?

No. It's not just the issue with the object browser.

One of the worst parts so far has been the error messages generated by the F# compiler when there is some problem with my F# code.
The error messages are often very confusing and do not lead to the solution of the problem.
But is probably the case at least partially due to my currently limited understanding of F#.
I guess once I fully understand F# the error messages become more clear and useful to me.

And it's just that tooling support for F# feels way worse than for C#.
For starters ReSharper does not support F#, which is a shame.

I could switch from VS to JetBrains Rider, but this requires a lot of (re-) learning and changing of habits, because working with Rider is very different than working with VS.
Also (at least on my machine) Rider is much slower than VS (even when I compare Rider to VS with ReSharper enabled).
Plus, having to use an IDE written in Java to write F#/.NET code, makes my heart bleed a bit. It just feels a bit wrong. :-)

Often when I write down the name of a type, Rider does not offer auto complete or to automatically add a proper import declaration.

Take for example this F# code:

[<Literal>]
let connectionString = @"Data Source=.\SQLSERVER;Initial Catalog=DB1;Integrated Security=True"

let test() =
    use cmd = new SqlCommandProvider<"SELECT Name FROM BusinessField", connectionString>(connectionString)
    cmd.Execute()

Rider does not offer to add a "open FSharp.Data" to import the type even tough the FSharp.Data.SqlClient NuGet package is installed.
It seems Rider is not aware of the types in the NuGet package.

I encounter such problems very rarely when writing C# code.

Another issue is that quite a few F# libraries seem to be broken or not up to date.
For example the FSharp.Data.SqlClient type provider is currently not working on .NET 6 (I think because of an issue with System.Data.SqlClient, see fsprojects/FSharp.Data.SqlClient#408).

Since I started learning F# there where many times where I felt like I am fighting against F# instead of benefiting from its rich feature set.
At least some of it is probably due to the fact that I am in fact still learning F#.
It will probably get much better over time.

But it doesn't feel as smooth as when I was learning C# back in the days (at least I think so :-)).

Another issue is the lack of a F# decompiler.
JetBrains dotPeek does not support decompiling MSIL into F#.
Neither does ILSpy or .NET Reflector.

There seems to be a plugin for ILSpy (https://code.google.com/archive/p/ilspy-decompilation-to-fsharp-plugin/), but that project seems to be abandoned.

Which brings me to another issue:
The MSIL code the F# compiler generates (when decompiled to C#) is often very complex and hard to read/understand.
It just feels like F# has to do a lot of heavy lifting to make F# code work on .NET, because most constructs of F# are not native to MSIL/the CLR, if you know what I mean.
So if you don't have access to the original F# code of an assembly, trying to understand its decompiled C# code in ILSpy can be very hard.

Another issue is the lack of good support for WPF.
Currently writing WPF applications in F# feels a bit cumbersome.
There isn't even a project template for a F# WPF application in Visual Studio.

Also, it would be really nice if I could mix F# and C# code in one project.
But I guess this would be quite a bit complicated to implement.

Mixing C# and F# in one solution could also be improved:
Suppose you have a solution with one C# console app project and one F# class library project.
I can reference the F# project in the C# project and use whatever the F# project exposes.
So far, so fine.

But when I change some code in the F# project (lets say I add a function to a module) IntelliSense does not pick up this change when I am in the C# code (Using the added function in C# gives me IntelliSense error).
I first have to rebuild the F# project to see the changes reflected in the C# project.
This is not how it works when having two C# projects.

Do you encounter times where writing other language than F# code in Visual Studio also feels a bit like notepad or is it specific to F#?

No, it's specific to F#.
C# support in VS (especially with ReSharper) is second to none as far as I am concerned.
I rarely fell that something is missing (apart from the horrible performance of ReSharper :-)).

Sometimes it just feels like the IDE is not helping me AT ALL writing F# code.

Having said that, I do still think that F# is a wonderful and very powerful language and that the projects I am working on can greatly benefit from using it.
F# made (and still does make) me view programing from a whole other perspective and I think what I've learned (and continue to learn) from it will also improve the way I write C# code.

I just wish MS would treat F# as a first class citizen like it does with C#.

But I guess this is a classic chicken-and-egg problem:
MS (seemingly) doesn't want to put more efforts into F# as long as the user base is relatively small (compared to C#).
And as long as MS doesn't improve the situation people are not as inclined to switch to F#.

@rent-a-developer, regarding object browser, can you adjust by using ILSpy or similar in meantime for similar needs? ILSpy shows a treeview which is pretty similar.

Thanks for the tip!

[cartermp]

FWIW I think it is far more valuable to improve things like this:

I first have to rebuild the F# project to see the changes reflected in the C# project.

than features like Object Browser, which tend to have quite low use. The inverse work is already done actually - you don't need to recompile C# code to see changes reflected in F#.

The error messages are often very confusing and do not lead to the solution of the problem.

This is something that I believe @dsyme and @KathleenDollard are very interested in learning more about. There's several areas known to be obtuse - the compiler doesn't give much help in solving the compile error - and there is a lot of value in understanding specific circumstances that lead to an obtuse error and confusing experience. It's complicated work but essential for people learning the language to feel like they're successful. If you don't have pains like this, my belief is that lack of support for miscellaneous things that Visual Studio ostensibly supports for all languages becomes less of a worry. But when there are issues like this, it makes everything feel worse.