Roslyn: Workspaces.Desktop.csproj not included in Compilers.sln

[Therzok]

Version Used:
dev.15.7.x

Steps to Reproduce:

1. Build on mac via ./build.sh --restore --build --test --mono
2. See that Workspaces.Desktop is not built
3. See that Workspaces.Desktop.Tests are not run

[sharwell]

IIRC, Compilers.sln only contains assemblies that build and run on non-Windows systems. Workspaces.Desktop would not be included under this filter.

[Therzok]

Well, Workspaces.Desktop doesn't seem to have Windows dependencies. Mono is a valid target (we're actually using it in VSMac)

[jmarolf]

@Therzok If I remember correctly Compilers.sln was originally created to contain just the compiler components not the IDE or workspace layers. Compilers.sln has now taken on the meaning of "Everything that targets netstandard1.3". It may make sense to Create a CrossPlatform.sln that includes all projects that will build in the mono environment. @agocke and @jaredpar would remember more of the history here.

[agocke]

It is only supposed to contain the compilers. We had crossplatform.sln but it contained even less than the Compilers. We can consider adding it back if workspaces are ready to run tests cross platform, but they should not be part of Compilers.sln.

[jaredpar]

The intent of Compilers.sln has changed a bit as we've evolved our cross platform story. I think everyone's understanding above has been correct at some point in time. At this point though Compilers.sln essentially exists to serve one purpose:

Contain the set of projects for which dotnet build can be successfully executed on any operating system.

It is perfectly acceptable, and expected, that this will lead to tests and projects which are specific to Windows being built on Linux. The reason it's called Compilers.sln is just a historical accident at this point.

The reason there is a gap for projects like Workspaces.Desktop.csproj is simply because this just isn't high on our priority list.

[jaredpar]

Build on mac via `./build.sh --restore --build --test
See that Workspaces.Desktop.Tests are not run

I definitely don't think that this should work. That implies that the tests run under CoreClr which is explicitly not supported by this project and there are no plans to add support there. We do have tests that run under Mono but we have to run them by specifically invoking mono on the xunit runner.

[agocke]

My intent when creating Compilers.sln was not as a cross-platform solution, it was to provide a workflow for compiler developers that provided fast access to the parts of Roslyn that they deal with 99% of the time on a daily basis.

If we need to a solution to build everything that runs cross-plat that's fine, but it has nothing to do with my original goal, which I still think is important. Compilers.sln is about half the size of Roslyn.sln. It takes probably less than half the time to load, because project load can increase greater than linearly. Most developers on the compiler team will still only touch something outside of the original Compilers.sln projects about 1/100 times. Every solution-wide operation, like find-all-references, gets faster and more useful when scoped to the domain we care about.

[jaredpar]

My intent when creating Compilers.sln was not as a cross-platform solution, it was to provide a workflow for compiler developers that provided fast access to the parts of Roslyn that they deal with 99% of the time on a daily basis.

Compiler team has partial ownership of workspaces 😄

If we need to a solution to build everything that runs cross-plat that's fine, but it has nothing to do with my original goal, which I still think is important.

Understand that was the original goal but as I noted it has evolved. Take for instance the inclusion of code style fixes. That is IDE only yet has long been part of the solution.

Compilers.sln is about half the size of Roslyn.sln.

The alternative is three solutions which has its own downsides.

[agocke]

Compiler team has partial ownership of workspaces 😄

We also have partial ownership of the EE. I didn't include it specifically because we don't touch it often.

Take for instance the inclusion of code style fixes.

I agree that they should also be ripped out.

The alternative is three solutions which has its own downsides.

It worked OK when we still had CrossPlatform.sln.

[Therzok]

@jaredpar I somehow missed the --mono in the copy paste. I apologize. Fixed up the OP.

So, I'm not saying that Compilers.sln should contain Workspaces.Desktop per-se, I think the request should be rephrased as solution that contains cross platform code that targets desktop.

[agocke]

Here are some numbers for Compilers.sln and Roslyn.sln:

Roslyn solution load + FAR on ISymbol.IsAbstract: 2 minutes 58s
Compilers solution load + FAR on ISymbol.IsAbstract: 1 minute 40s
Compilers clean build: 01:24.63
Roslyn clean build: 3:33.69

[jaredpar]

I somehow missed the --mono in the copy paste

Gotcha. Yes that should eventually work. I say eventually though because we have a long way to go. We've been chipping away at this but due to some decisions we made early in our test design it's a lot of work to get everything moved over to CoreClr and Mono. The approach we've been taking for each test project is is the following:

1. Change it to multi-target net461 / netstandard2.0
2. Get it running on CoreClr on Windows
3. Get it running on CoreClr on Linux
4. Get in running on Mono on Linux

The process is getting faster as we've worked out some core infrastructure issues. But each project is still a bit of work to get going.

It's possible the MSBuild dekstop project will be cheaper given it probably doesn't have the AppDomain baggage the compiler does. Can basically skip steps 2 and 3. But i still imagine it will be a while before we have that running.

[Therzok]

Going to close this out. It's not a big deal for me to add the needed projects to whatever solution.