FSharp.Compiler.Private files not showing

[NatElkins]

Repro:

1. Checkout https://github.com/Microsoft/visualfsharp
2. As per README.md, run sh ./build.sh.
3. Let it do its thing.
4. When it's done, open FSharp.sln in Rider.
5. Look at FSharp.Compiler.Private in the Solution Explorer.
6. Look at the source of the project file.

Majority of files are missing. Is that expected?

[NatElkins]

And I'm on macOS using 2019.1.

[NatElkins]

Also the files appear without issue using VS4Mac.

[NatElkins]

@auduchinok This still appears to be an issue with the following version:

JetBrains Rider 2019.2.2
Build #RD-192.6584.65, built on August 28, 2019
Licensed to Masse / Nathaniel Elkins
Subscription is active until September 25, 2019
Runtime version: 11.0.3+12-b304.39 x86_64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.14.5
GC: ParNew, ConcurrentMarkSweep
Memory: 1450M
Cores: 12
Registry: ide.tree.horizontal.default.autoscrolling=false, performance.watcher.sampling.interval.ms=200, ide.borderless.title.product=false, performance.watcher.unresponsive.interval.ms=1000, ide.tooltip.initialDelay.highlighter=0, search.everywhere.settings=true, parameter.info.max.visible.rows=10, ide.win.file.chooser.native=true, ide.borderless.title.project.path=false, actionSystem.fix.alt.gr=false, search.everywhere.pattern.checking=false, ide.tooltip.initialDelay=0, ide.borderless.title.classpath=false, ide.require.transaction.for.model.changes=false, rider.enable.designer.winForms=false
Non-Bundled Plugins: IdeaVIM, io.protostuff.protostuff-jetbrains-plugin, net.seesharpsoft.intellij.plugins.csv, AWSCloudFormation

Any update on this?

[auduchinok]

There's a bit of MSBuild magic here and there in the compiler solution, along with additional support for working on FSharp.Core and referencing it as a project inside FCS itself. We likely need to add some special handling too. As a workaround, it's possible to work on the compiler via fcs/FSharp.Compiler.Service.sln solution, which contains most of the compiler code and references FSharp.Core as a compiled dll. Removing one of the target frameworks also significantly improves performance. There's no workaround for working on FSharp.Core for now if it doesn't work.