Rework solution management code to better support project types

[davidfowl]

There are 4 different kinds of "solutions"

1. A visual studio solution (.sln file)
2. A folder without an .sln file, that contains multiple subfolders
3. A single folder project
4. Unity solution (special case?)

Within these solution, there can be various project types

• MSBuild based projects
• ASP.NET 5 projects

Realistically, MSBuild based projects will always have a project file. ASP.NET 5 projects on the other hand don't require it. ASP.NET 5 project types can live in a .sln file side by side with MSBuild project types.

Given these new requirements we should do the following:

• The SolutionPicker should determine which one of the 4 solution types gets loaded
• Project creation should be abstracted so that these project types can live side by side within the same solution (when it makes sense).

[nosami]

Some notes from our chat.

We need to drop

XDocument AsXml();
void Save(XDocument project);

from IProject. They don't make sense for ASP.Net 5 projects.

We need the following solution types :-

• FolderBasedSolution
• SolutionFileBasedSolution

and the following project types :-

• MSBuildProject
• AspNet5Project

Currently the server is started in either sln mode or aspnet5 (folder) mode. This isn't correct as they aren't exclusive.

We need to be able to start the main solution from here https://github.com/aspnet/Entropy . This contains a number of kproj projects. On the DTH branch, we have partial support for loading the projects individually, but not as a combined solution.

We also need to support what DTH calls "RawReferences" which are assemblies represented as a byte array.

[nosami]

A single folder project is just a project, no? OmniSharp folder mode was only added as a quick way to get started with vnext projects, back when the references were just dlls inside the project folder.

[davidfowl]

@nosami I think there's always a solution. That simplifies things and makes it so we don't have to special case anything.

[nosami]

I've ended up taking a slightly different path. We either start off with an MSBuild solution or a folder based solution, but either of those could also contain a collection of AspNet5 projects ( found by scanning )

I'm not sure if there are any downsides to this way off thinking about things, but I can now load Entropy and KRuntime as solutions, with each project getting its own isolated references from DTH.

Haven't had time to give it much testing, and RawReferences still don't work, but I think it shows that the idea could be sound.