[WIP] Project Load improvements

[cloudRoutine]

It'd be great if I could get some additional eyes to review this as I work towards addressing #2793

This first change is to simplify an initial project loading process that seems unnecessarily complicated. I've opened a bunch of slns after making the change, they all seem to open around the same speed or slightly faster, I haven't noticed anything breaking yet, but maybe the CI will catch something...

[majocha]

Apparently there were some slowdowns when doing this. That's why the code is so convoluted. It waits for full solution load.

However I'm all for simplifying this.

[cloudRoutine]

@majocha I've found that I just need to build a new way to add the project references into the fsharpprojectoptions being created and then the references to LanguageService & LanguageService.Base can be removed from FSharp.Editor.

initialize has been cut down to

    override this.Initialize() =
        base.Initialize()

        this.Workspace.Options <- this.Workspace.Options.WithChangedOption(Completion.CompletionOptions.BlockForCompletionItems, FSharpConstants.FSharpLanguageName, false)
        this.Workspace.Options <- this.Workspace.Options.WithChangedOption(Shared.Options.ServiceFeatureOnOffOptions.ClosedFileDiagnostic, FSharpConstants.FSharpLanguageName, Nullable false)
        
        this.Workspace.DocumentClosed.Add <| fun args ->
            tryRemoveSingleFileProject args.Document.Project.Id 
            
        Events.SolutionEvents.OnAfterCloseSolution.Add <| fun _ ->
            singleFileProjects.Keys |> Seq.iter tryRemoveSingleFileProject
        
        this.Workspace.WorkspaceChanged |> Observable.add (fun args ->
            match args.Kind with
            | WorkspaceChangeKind.ProjectRemoved ->
                projectInfoManager.ClearProjectInfo args.ProjectId
            | _ -> ()
        )
        
        let theme = package.ComponentModel.DefaultExportProvider.GetExport<ISetThemeColors>().Value
        theme.SetColors()

SyncProject is out, SetupProjectFile is out SetupNewTextView doesn't use the project site anymore.

It's not doing great on @saul's Dense generated project when it's been cut down to 50projs, so I've still got a ways to go with this

[cloudRoutine]

Turns out it was a biiiiit more complicated than I initially thought 😆
I think the introduction of the ProjectTracker in a few more places may help with the synchronization, but I need to do some more experimenting to find out for sure

Depending on how well the solution event advising and project tracker keep things running in the background and hooked up to the workspace, it might be possible to cut out a few more large chunks of the current logic.

All usage of ProjectSitesAndFiles has been removed,

• abstractProjects need to be disconnected and disposed properly
• FSharpProjectOptions need the rest of their data filled properly (compiler flags etc)
• Try to make more of the initialization and loading aync or deferred
• Testing for ProjectOptionsCache
• Fix SingleProjectFile, Script FSharpProjectOptions generation and ComputeSingleFileOptions

[saul]

Can we minimise the diff? So much code has just been moved around and it makes it hard to see what's actually changed

[saul]

We need to wait on solution close, and put this in a while loop (just as the old code did).

[cloudRoutine]

Why does it need to wait on solution close? i didn't really understand that part

[majocha]

If I remember correctly performance was worse with projects being setup during solution load. We don't want this the first time and also we want to avoid it on subsequent solution openings.

[majocha]

I admit it was done in a crazy way. Probably using UIContexts would be better.

[majocha]

why not use lazy instead?

[majocha]

That was here, because workspace doesn't trigger DocumentClosed on open files when the solution closes. There was some bug associated with it IIRC.

[cloudRoutine]

@davkean I've been told you know how to disable/mute the msbuild output in the debug pane. If I could get rid of that noise it'd make working on this less painful.

[davkean]

@cloudRoutine TBH, I have no idea how F# project system calls MSBuild or who puts the logs into the Output window. The legacy C# project system calls into the default IVsBuildManagerAccessor and I didn't think it logged to the debug pane.

[davkean]

Can you reverse the layout/formatting changes (submit them in a different review to make them) to make the diff easier to read?

[cloudRoutine]

@davkean don't worry about it, I've been getting nowhere with this

[saul]

@cloudRoutine a bit late (considering you've closed this), but I know where you can look for this. See ProjectNode.SetDebugLogger in ProjectNode.cs in the base project project.

[cloudRoutine]

@saul thanks for the tip, but I have no intention of coming back to this

[saul]

Any particular reason? I plan on tackling the project load performance issues soon as it's crippling us at work. Any tips would be great :)

[cloudRoutine]

Cause it's miserable to work on, the integration with lower layers of the project system were deeper than I originally realized and there's a bunch of underlying machinations in the languageservice and languageservice.base that I didn't get into thoroughly investigating.

The interactions between the solution and the workspace are obtuse, and the projectsitesandfile implementation is an odd one I was hoping to be able to factor out, but it seems like it'd take a lot more digging and untangling than I'd already done.

I'd thought I'd made some progress here, but I couldn't figure out why the project references weren't loading properly, if you want to try to pick up from here that'd be the first thing to address.

The reactor seems to be starting up when VS is opened, before any solution has been opened, that probably shouldn't be happening.

If you're wondering why I changed the projectinfo manager to work mainly as a wrapper around the projectinfocache, it was to make it easier to add it into a workspace I built to use for roslyn feature tests (I didn't get around to PR'n it though)

@saul I'll try to answer any other questions you have, but I'm not sure I really learned much concretely while working on this 😆