Discussion for implementing checker.GetProjectOptionsFromProjectFile in a separate process

[7sharp9]

Issues #366 and #342 both require either assembly redirects in a seperate process or some form of reflective binding. I created this issue to discus how we want this implementing.

• How do we want to proceed with this reflection or a separate process being called with assembly redirects
• Do we want to add an extra parameter to the existing function to force running in a separate process, add a new function, or simply update the current function to always run in a separate process
• Running via a separate process seems the simplest option but how to we represent the output data

Rather than a separate process, maybe we could use AppDomainSetup.ConfigurationFile and AppDomain.CreateDomain() before running checker.GetProjectOptionsFromProjectFile in the new appdomain.

//cc @dsyme @rneatherway

[rneatherway]

How do we want to proceed with this reflection or a separate process being called with assembly redirects

How do you set assembly redirects on a new process?

Do we want to add an extra parameter to the existing function to force running in a separate process, add a new function, or simply update the current function to always run in a separate process

I think it is fine to always run in a new process.

Running via a separate process seems the simplest option but how to we represent the output data

You said before that XS runs the resolution in a separate process, would you mind linking to that (sorry if you already did before)? I'm wondering how they handle sending the data back and forth.

Rather than a separate process, maybe we could use AppDomainSetup.ConfigurationFile and AppDomain.CreateDomain() before running checker.GetProjectOptionsFromProjectFile in the new appdomain.

Nice idea, but I don't really know anything about AppDomains. Do they provide sufficient isolation?

[7sharp9]

I believe the format is normal remoting.

It uses a RemoteBuildEngine: https://github.com/mono/monodevelop/blob/5436cd09a80af3eb9da1200c76a9c410c03bf7d3/main/src/core/MonoDevelop.Core/MonoDevelop.Projects.Formats.MSBuild/RemoteProjectBuilder.cs#L39

Which is created here:
https://github.com/mono/monodevelop/blob/6e87c2c761c7bf22b2c079f9818c7f4967b3bb1f/main/src/core/MonoDevelop.Core/MonoDevelop.Projects.Formats.MSBuild/MSBuildProjectService.cs#L504

In this instance the process thats invoked (MonoDevelop.Projects.Formats.MSBuild.exe) has an assembly redirect in its config.

[rneatherway]

Sorry, I don't know anything about .NET remoting. Is it possible to return .NET types? So the idea here is to have a little shim executable that uses MSBuild, and it uses an assembly redirect to get the most up to date version available? That sounds perfect, as presumably then FCS the library could lose the dependency it currently has. If you find time to start a branch, I will try to help testing and debugging it.

[7sharp9]

Ive ended up doing this locally as part of the F# addin

[rneatherway]

Ah cool, so it works for iOS and Android now? Could you link me to the implementation so I can copy it please?

[7sharp9]

Ive only tried it as a prototype, Ive had to leave it for now to work on
even more serious critical fixes, as soon as thats done Ill test fully
before merging in.

On 31 July 2015 at 10:15, Robin Neatherway notifications@github.com wrote:

Ah cool, so it works for iOS and Android now? Could you link me to the
implementation so I can copy it please?

—
Reply to this email directly or view it on GitHub
#371 (comment)
.

[rneatherway]

Implemented in #470