Roslyn: Create solution file containing only projects necessary for IDE feature development

[alrz]

Roslyn.sln is pretty huge and slows down the development cycle, it's only useful when you want to work across all layers. We have Compilers.sln but there is no Features.sln for IDE-only work. I think compiler tests, for example, doesn't need to be in this solution.

It's also useful to separate C# and VB. I currently workaround this by manually adding projects to a new solution, but it does not always contain exactly what I need for a particular work. Would be nice to have them in the repository.

The question is how we can seperate things out in a couple of smaller solution files, each suitable for a specific feature-work.

[sharwell]

@alrz I would prefer not to do this. I understand where you are coming from, but it has a few downsides:

• It increases maintainability costs (though not to the extent it once did)
• One of the most valuable things about the current solution is it helps us get feedback about the performance with a wide variety of developer focuses and workflows

It's probably hard to see as an external contributor, but performance is an intense focus for many people here. I'd love to work with you to identify the particular issues most impacting your workflow, and use that to improve performance of Roslyn.sln to the point that it beats even what you expected from a smaller 'Features.sln'.

[alrz]

It's not just my workflow, there are obvious reasons that simply loading more projects would hurt performance. Examining all tests (for test explorer), symbols (for code navigation), assemblies (for incremental compilation), etc, etc. Surely, there is room for improvement in all these, but I think separating things out is the cheapest workaround that we can do right now and not slow down the whole development process until we actually do the work to make things faster.

performance is an intense focus for many people here

That's why I'm suggesting this in the first place, only that I'm on the other side of the equation. I want the IDE to be as responsible as it should, so I need to tune the solutions for that, until maybe someday we can provide the same experience for Roslyn.sln.

[CyrusNajmabadi]

I'm with sam on this. The experience with Roslyn.sln is not good. But if we don't fell the pain of that regularly, we're far less motivated to improve the performance of things. That means customers who do have solutions like Roslyn.sln (or worse) are far less likely to have their perf issues addressed.

We also discover perf problems far sooner with a solution like Roslyn.sln. For example, when the new project system was moved to, there were awful things found and fixed for precisely this reason.

[CyrusNajmabadi]

It's not just my workflow, there are obvious reasons that simply loading more projects would hurt performance. Examining all tests (for test explorer), symbols (for code navigation), assemblies (for incremental compilation),

Here's the thing though we don't want any of those to hurt performance. CodeNavigation (i.e. NavigateTo/FindAllReferences) should have good performance regardless of solution size. If it doesn't, we shoudl fix that. For example, FindAllReferences puts the majority of its cost into building its index, so that searching and validating results can hopefully be fast, and only cost linearly with the amount of actual references. Similarly, NavigateTo and FAR are both designed to only need to update their indices when a file is edited (or we change the index format and have to regenerate the entire thing).

Getting this stuff to have good perf characteristics (i.e. fast results, low memory, small impact to produce/compute data) on small/medium projects isn't hard. But getting that to scale up with solution size is. And that's why we very much benefit from Roslyn being huge.

--

Now, if that is painful for you, i totally get why that would be frustrating. If you wanted to make your own RoslynAlrz.sln with the parts unnecessary for you cut out, i think that would be fine. But i would prefer that not be checked in.

[alrz]

we don't want any of those to hurt performance

Me too. but that's the thing I want now, not VS2020. I guess the fastest solution is to have more solutions?

[alrz]

if we don't fell the pain of that regularly, we're far less motivated to improve the performance of things.

I don't mind doing this in my worktree. just wanted to know if anyone else has this problem, so we can fix it once and for all. apparently that's actually the case but we need to experience the pain to get motivated.

[CyrusNajmabadi]

appearly that's actually the case but we need to experience the pain to get motivated.

Yup. Having to live with the pain is one of the best ways to get things looked at :)

[alrz]

now if you need anyone else to also feel that pain, it's kinda sadomasochism, but I agree it works.

Seriously, Roslyn.sln won't go anywhere, so you can force yourself to only work on Roslyn.sln to appreciate how it actually feels.

[alrz]

I fully understand the thought process here, but I think the only ones that need to know about performance problems are the ones working on performance problems. not anyone else has to get involved in this. I guess that's a pretty reasonable request.

[sharwell]

now if you need anyone else to also feel that pain, it's kinda sadomasochism, but I agree it works.

We shaved 4+ minutes off of test discovery time in the last 3 weeks by using Roslyn.sln to place pressure on the appropriate teams.

[jmarolf]

@sharwell and @CyrusNajmabadi 's arguments make sense and I personally want us to focus on rapidly getting to a place where VS 2017.7 or 2017.8 are so good this doesn't matter. At the same time I don't want to cause contributor pain while we get there.

We essentially have 4 layers today that could be split into separate solutions:

• Visual Studio Integration
• Features
• *Workspaces
• Compilers

The main question I have, if we were to even entertain doing this, is how does the developer deploy and test their changes? Today you just build Roslyn.sln and everything gets deployed (assuming something doesn't go wrong with the VSSDK). If I make a change in Features what gets deployed? Roslyn expects all of its dependencies to be deployed in lock-step with matching version numbers. This sort of sinks the idea for me as we'd need to support more deployment scenarios and have build correctness tests to ensure we don't break things.

However, there might be some niceties about doing this so we actually enforce our layering strategy, but I think that can be accomplished other ways.

In addition, everything except for the Visual Studio Integration layer can be made to build cross-platform on linux, mac, or windows. I would be fine if someday we re-created the CrossPlaform.sln to do just that.

So @alrz, I think you've identified a contributor pain point that we need to have and answer for. I'm not convinced that separate solutions is the right fix, but I would like us to come up with something.

[sharwell]

Tentatively marking as Won't Fix due to the maintenance overhead and current priority of an alternative solution, but will leave it open until we can review the proposed resolution in a design review.

[sharwell]

We decided not to pursue this at this time.