Create a client/server execution model for design-time operations

[natemcmaster]

Current design
As of #5334, design-time operations execute using two processes, the "dispatcher" and the "runner". The dispatcher (dotnet-ef and PMC) handles interaction the project system and IDE. The runner (ef.exe/ef.dll) is a console application that loads the users assemblies and executes parts of user code in order to discover EF metadata. Dispatcher and runner communicate using standard streams (stdin/stdout/stderr).

Problems the approach begets

Standard streams is not available in all app models. In app models where standard streams are not available, we are forced to imitate the app model using a different runtime.

Example: there is no "console application" for running .NET Core and .NET Native for UWP apps. So instead, we use a .NET Framework console app to load/execute UWP assemblies. The mechanisms for assembly loading and execution are slightly different between .NET Framework and UWP. This the root cause of #5471, #5945, #3543, #4812 and others.

As .NET Standard expands to new app models, this same problem will likely apply to other .NET runtimes that may not support stdin/stdout as method of IPC. This will likely include .NET Native for dotnet-cli, UWP, and Xamarin.iOS/Android/Mac.

Proposed design changes

1. Using a networking stack instead of standard streams to communicate metadata between the app and the project system/IDE integration.
2. Use a client/server execution model. The server handles interaction with the project system and IDE. The client executes parts of user code to discover EF metadata.

There is subtle but important distinction between server/client and dispatcher/runner:

• In dispatcher/runner, the runner loads user code. i.e. the user doesn't need to add additional code to their project.
• In server/client, user code loads the client. i.e. the user will need to add code near the program entry that will run the design client (when appropriate).

[divega]

Triage: we believe (for now) that we don't need to do this because a simpler solution based on binding redirects should work.

[divega]

👍 on propose-close.

Sounds like when we run out of workarounds we can go a long way by switching to .NET Core instead of .NET Framework (part of #9666).