Fix references to Exe projects

[dsplaisted]

Fix #1675

Include runtimeconfig.json and deps.json in files that are copied from a referenced Exe project.

Note that I also included a refactoring of how you can create test PublishCommands, which touched a lot of files. So it should be easier to review this commit by commit.

Currently, it still fails if a self-contained project references a framework-dependent project, or vice versa. When a self-contained project references a framework-dependent project, running the referenced project fails with the following error:

It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '5.0.0' was not found.

• No frameworks were found.

You can resolve the problem by installing the specified framework and/or SDK.

I suspect this may be because some of the host files (hostfxr or something) are different between self-contained and framework-dependent apps, and are interfering with each other. @vitek-karas @agocke What do you think?

When a framework-dependent project references a self-contained project, it fails because the runtime pack assets aren't copied. However, if we were to fix that I think we might run into the same issues that we get when referencing a framework-dependent project from a self-contained project.

@jaredpar @ericstj @ViktorHofer

[vitek-karas]

The mismatch between two exes - one being SCD and the other FDD won't work. Host is kind of dumb (for historical reasons). When it looks for hostfxr it first looks into the app's directory and if it finds it there, it will behave as SCD until it reads the runtimeconfig: https://github.com/dotnet/runtime/blob/33c9d5afdb3f165599ab0e858652a4d416d34a9e/src/installer/corehost/cli/fxr_resolver.cpp#L60-L65

The result of this is that doesn't look at DOTNET_ROOT because it thinks it's running SCD and thus uses the app's directory as the "dotnet root". Later on when it finds out it's an FDD (by reading runtimeconfig) it will still use the app's directory as "dotnet root" and will try to find shared frameworks in it (this is totally dumb) - which will obviously fail.

On Windows this is even worse because if DOTNET_MULTILEVEL_LOOKUP is enabled (which is the default), it will actually fallback to search global locations and it might find matching framework there. In which case it will run just fine. But it will still ignore DOTNET_ROOT.

Given the challenges of the reverse where the main project is FDD and referenced one is SCD (copying over runtime pack assets), I would probably go with disabling the mixed scenarios explicitly. Let's make SDK fail in those cases. We know it won't work (or it will be unreliable).

If the two match, it should work just fine - assuming SDK does version validation of the frameworks and performs necessary roll-forward and so on. The interesting case would be to try what happens if the main project is net3.1 and the referenced project is net5.0 for example and they're both SCD.

Note that host will not perform any version validation for SCD apps - it will blindly load what's in the .deps.json and on disk. It only performs framework version resolution for FDD apps.

[vitek-karas]

Related to this - if we're now officially supporting building multiple exes into one output we should also consider what happens with publishing. Do we publish each project separately and then just copy them into one output location? Or do we somehow publish them "together"?

• ILLink - this could be made to work for SCD - we would pass multiple entry points to linker and it would trim the framework for "both". Getting the right settings might be challenging though.
• Single-file - not sure what the desirable effect is in this case - but there's no good way to make this work for "merged" publish
• CrossGen - right now probably relatively easy since it runs per-assembly, but going forward would have similar problems as single-file with large version bubbles.

[wli3]

No other way but need to write the same logic twice for publish and build?

And I cannot find the logic of copying the referenced exe, how that worked?

[dsplaisted]

The logic is not quite the same. The files can be different between build and publish in some cases.

For copying the referenced exe: The apphost is added as a None item with CopyToOutputDirectory=PreserveNewest in the _ComputeNETCoreBuildOutputFiles, with Link set to the target filename. That gets gathered by the targets that get items to copy to the output directory from referenced projects.

[wli3]

Looks good. Had few questions. And update the comments

[wli3]

update this comment too

[wli3]

update the comment after Vitek's reply

[dsplaisted]

@vitek-karas We don't have a good way of checking that a FDD isn't referencing an SCD, or vice versa. Also, it's possible that the referencing app could be calling into APIs of the referenced project instead of expecting it to run as a separate app from the same folder.

So for now I'd like to leave it as it is in this PR, where you can reference the Exe project but it won't run correctly if there's an FDD/SCD mismatch. How does that sound?

[vitek-karas]

As a point in time (to make this PR reasonable) I think it's OK. But I don't think we should ship that way. Or rather, there are already holes in the SDK where some weird combination of inputs creates output which is somehow wrong without SDK warning/failing, or SDK silently ignoring settings (for example building a classlib as self-contained - no warning, ignored; publishing class lib as self-contained - the output is actually SCD which is useless - won't work). I think we should try move to a place where if the SDK doesn't warn/fail, it produces output which should work and it follows the inputs (so if I ask for self-contained I either get a working SCD, or SDK warns/fails)
.
If FDD references SCD we know the output is effectively broken - so SDK should probably fail on this.

[dsplaisted]

I filed #15117 to track generating an error if there's a SelfContained mismatch on an Exe-to-Exe reference.

@vitek-karas Feel free to file issues for other invalid property combinations where you think we should generate an error.