Allows .NET Core apps to be optionally run using the Mono runtime

[marek-safar]

Fixes #6043

Requires dotnet/sdk#2260

[peterhuene]

If we take this, I think it should target release/2.1.4xx rather than master.

[dsplaisted]

@weshaggard @ericstj @terrajobst @eerhardt Is it reasonable for Mono to support running apps compiled for .NET Core? @migueldeicaza has requested that we add an option to do this in the .NET Core SDK, but I'm wondering now if a compiled .NET Core app is going to depend only on APIs/"contracts" that Mono can support, or if it would end up depending on implementation details of .NET Core that Mono is unlikely to be able to support (for example depending on the naming of System.Private.CoreLib, or locating assemblies based on the deps.json file).

[ericstj]

Seems like this would be broken for an unpublished app unless mono reads the deps file to load from packages.
It'd also be broken for a published self-contained app since that would have the .NETCore copy of the runtime assemblies (as well as the exe host). These wouldn't work on Mono's runtime / corelib.
It'd also be broken for a portable app that uses RID-specific assets unless mono reads the deps file and understands which RID specific assets are best to load.
We typically do not ship things that depend on System.Private.Corelib in OOB packages so I don't expect that to be an issue, but we do have plenty of things that ship in packages where mono would want to prefer it's own copy. I know we did some work to enable that, but not sure if its made it out broadly. Without that I'd expect things might break.

I suppose all these could be fixed by making the mono command do a publish, ensure the app wasn't self-contained, and force a RID. I'd expect to see a spec describing this or a backlog of issues to complete this experience.

I do think dotnet run ought to have a switch for running desktop apps on mono, does CLI do this? That seems like a good first step, then try to identify all the important issues to enable the .netcore version and drive those fixes in.

[dsplaisted]

I do think dotnet run ought to have a switch for running desktop apps on mono, does CLI do this? That seems like a good first step, then try to identify all the important issues to enable the .netcore version and drive those fixes in.

https://github.com/dotnet/cli/issues/6042 is filed for this scenario

[nguerrera]

I do think dotnet run ought to have a switch for running desktop apps on mono, does CLI do this?

Not yet, and I agree that it should. I also agree in priniciple that it would be better to start there. However, we still don't have a good story for building net46 apps with dotnet / core msbuild, and that will block that experience too. :( The official nuget packages for framework reference assemblies can't come soon enough! Note that there are architectural problems in non-Mono builds of msbuild that prevent it from working with the reference assemblies that are distributed with Mono.

Seems like this would be broken for [several cases]

@marek-safar @migueldeicaza Do we have a commitment that mono will work for .NET Core apps, including understanding deps.json and all the rest?

[marek-safar]

I implemented the CLR switch to run netcore apps first because that's what dotnet CLI supports best right now. I had quick look at extending it to also work with net4x apps but that support is still pretty iffy on non-Windows due to problems with reference assemblies and if I remember correctly it's explicitly blocked with an error message when you try to run them on non-Windows.

I don't think we want to commit ourselves to support all possible coreclr executing scenarios but we want to support as many as we can. This change enables the basic scenarios and would help us to explore what else we need to change and implement to support the complex scenarios.

[nguerrera]

I don't think we want to commit ourselves to support all possible coreclr executing scenarios but we want to support as many as we can. This change enables the basic scenarios and would help us to explore what else we need to change and implement to support the complex scenarios.

From a user perspective, the scenarios that @ericstj described are not really complex. For example, without deps.json support, every non-framework nuget reference will fail to load.

The assembly loading errors are not going to be very friendly either. See here where users were trying to load netcoreapp sdk build tasks on Mono: dotnet/source-build#125 (comment). Right now, I can simply say that this isn't supported, but once we merge this, it will get harder to communicate.

So, if we go ahead, I would like to have a doc link to point people when things blow up. It should describe what works today and what doesn't and that it is currently an experimental feature. I want to avoid setting expectations too high, and I want it to be clear that the scenarios that do not work are not bugs in dotnet run implementation, but rather unimplemented aspects of the netcoreapp TFM on Mono.

I implemented the CLR switch to run netcore apps first because that's what dotnet CLI supports best right now.

This is true at the moment, but the work to make net4x work well x-plat is very well understood: https://github.com/dotnet/designs/pull/33/files?short_path=4c085c4#diff-4c085c464d992b00504305a5996f804c. We have working packages based on this design that we're using in our own builds.

cc @KathleenDollard @richlander @terrajobst

[nguerrera]

Technical note: to resolve merge conflicts in .xlf files, just accept whole file from master and regenerate.

[migueldeicaza]

My feeling is that the "published self-contained" app would either be self-contained with CoreCLR, or self-contained with Mono, and we could not interchange the runtime on the self-contained app. But the user should be in a position to configure how the self-contained publishing would be, so that should not be a problem we need to concern ourselves with.

[nguerrera]

@migueldeicaza I agree on self-contained. It's not an issue here. dotnet run will not run the published app.

Let's try one scenario at a time:

1. dotnet new console
2. add nuget reference
3. use nuget reference in code
4. dotnet run --clr mono

My understanding is that this will fail now.

[dasMulli]

So --clr mono would also need to set -p:CopyLocalLockFileAssemblies=true.
From what I understand, VS web project system also wanted to do this for safer IIS express hosting when starting such a profile.

[nguerrera]

There are several issues with CopyLocalLockFileAssemblies for netcoreapp. IIS has targets that work around them, but they're messy and a frequent source of bugs. I'd love to avoid another component going down that path. We are thinking about changing the whole publish/build dichotomy longer term and that may lead to happiness here.

My concerns are still about expectations in the short term.

[dasMulli]

We are thinking about changing the whole publish/build dichotomy longer term and that may lead to happiness here.

cool, is there a tracking / discussion issue somewhere?

[nguerrera]

I am looking into sharing some discussion on it with you. I should say that when I say "thinking" it is just that. There's no commitment or firm design plan or anything like that.

[marek-safar]

From a user perspective, the scenarios that @ericstj described are not really complex. For example, without deps.json support, every non-framework nuget reference will fail to load.

I'd say this is complex scenario you can build pretty large app with framework only nugets. There are also scenarios where someone wants to verify behaviour or performance of tiny block of code all this would be made much easier.

The assembly loading errors are not going to be very friendly either. See here where users were trying to load netcoreapp sdk build tasks on Mono: dotnet/source-build#125 (comment). Right now, I can simply say that this isn't supported, but once we merge this, it will get harder to communicate.

You can point them to report Mono issue, we could even make the error message nicer and most likely will if this turns out to be common problem.

If you think the external nugets will be the major problems for all users of this feature then we can look into it sooner than later but it might turn out not to be.

[livarcocc]

We will do this as part of NET 5. Closing this PR.