HotReloadMSBuildWorkspace

[tmat]

Refactors BuildHost and MSBuildProjectLoader to allow dotnet-watch to populate workspace in-proc based on already evaluated ProjectInstances (loaded via ProjectGraph).

• Factors language specific retrieval of command line arguments out of ProjectFile into separate types: XyzProjectCommandLineProvider.
• Factors construction of ProjectFileInfo based on ProjectInstance into a separate type: ProjectInstanceReader. The reader takes project instance and optionally MSBuild Project and extracts the necessary info from its properties and items. The Project is optional - it is only needed to populate FileGlobs.
• Adds HotReloadMSBuildWorkspace - this is a replacement for dotnet-watch's IncrementalMSBuildWorkspace
• Adds interface IProjectFileInfoProvider that abstract away retrieval of ProjectFileInfos. MSBuildWorkspace uses an implementation that dispatches to OOP while HotReloadMSBuildWorkspace uses impl that calculates the information directly (in-proc) from project instances provided by dotnet-watch.
• Updates BuildHost project to build first-class NuGet package.

dotnet-watch usage: dotnet/sdk#52163

[tmat]

@jasonmalinowski @DustinCampbell ptal

[jasonmalinowski]

Leaving comments so far; no real concerns so far.

[jasonmalinowski]

Just a note to reviewers, this is moving from https://github.com/dotnet/sdk/blob/2b7468dad75a2c8dc419cd30da4443ac6d699aa6/src/BuiltInTools/Watch/HotReload/IncrementalMSBuildWorkspace.cs.

[jasonmalinowski]

Just to document it somewhere, yes that can happen if a file is added twice. Or is added as both a source file and an additional file. None of these are "real" scenarios, but can happen in broken project scenarios. The only expectation is we don't crash. There might be a bug here since maybe if a source file is being added as an additional file we might try to reuse the same ID which would be bad in this case. Maybe file a bug for tracking, if we refactor this later this code might go away.

[jasonmalinowski]

Fantastic job cleaning this up. Although I imagine there's further refactorings here that will delete some of the code that migrated, I'm much happier to see all the "complexity" of the loading be in Roslyn rather than being in the SDK. That means we can clean it up without cross-cutting changes.

[tmat]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).