Separate project-system-tools into a frontend and backend structure #346
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…o interfaces and build and buildSummary types
eric62369
requested review from
drewnoakes,
KirillOsenkov,
panopticoncentral,
dmonroym and
jjmew
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description:
In preparation of getting project-system-tools on Codespaces, I need to insert an API that the client can use to communicate between the server and client.
Currently, BuildTableDataSource.cs is used as a bridge between the UI and the loggers and data that collect the binlogs from VS.
The Build.cs type in ProjectSystemTools/BuildLogging/Model is also involved in retrieving log files from the loggers and giving access to them to the UI, so a new BuildSummary.cs (and UIBuildSummary.cs) type is introduced to be exchanged between the client and server sides instead of Build.
In order to insert the Codespaces API in between the client and server side, BuildTableDataSource.cs is being split into a side that lives on the client and the other side on the server.
The new structure for ProjectSystemTools:
There are new namespaces now:
BuildLogging/Model/BackEnd
BuildLogging/Model/RpcContracts
BuildLogging/Model/FrontEnd
BuildLogging/Model/BackEnd
This is responsible for acting as a server for the frontend, where most server requests are handled in BackEndBuildTableDataSource.cs. BackEndBuildTableDataSource.cs also implements the ILoggingDataSource.cs and ILoggingController.cs interfaces.
This namespace contains all the Logger classes needed to collect build logs.
This namespace does not import the FrontEnd namespace.
BuildLogging/Model/RpcContracts
This contains the IBuildLoggerService.cs interface, which connects the frontend to the backend.
This interface is implemented by BuildLoggerService.cs in the BackEnd namespace.
IBuildLoggerService.cs will eventually be the main service that is proffered by the IServiceBroker in a Codespaces scenario.
BuildLogging/Model/FrontEnd
Contains FrontEndBuildTableDataSource.cs, which implements the IFrontEndBuildTableDataSource.cs
FrontEndBuildTableDataSource.cs handles giving the UI the data about collected build logs. It uses the IBuildLoggerService.cs interface to send requests to the backend.
This namespace does not import the BackEnd namespace.
The BuildSummary.cs class:
The Build.cs class:
Note:
VS was updated to use an updated SDK, so this workaround was added to Directory.build.props: dotnet/project-system#6458
End goal of this PR:
Have project-system-tools be separated into a client and server side, splitting apart files that have a mix of UI related and data related logic.
Make sure that non-Codespaces project-system-tools works properly in this new frontend backend structure.
Linked Github Issues:
Build ID system uses int type as ID: #345
Continuation of #343