Self-contained publish of a Exe project referencing another Exe project

[ivanwick]

Steps to reproduce

1. mkdir projA projB
2. dotnet new console --output projA
3. dotnet new console --output projB
4. dotnet add projA reference projB
5. dotnet publish projA --configuration Release --runtime win-x64 --output out

Actual behavior

publish fails with

C:\Temp\projB\projB.csproj : error : The project was restored using Microsoft.NETCore.App version 2.1.1, but with current settings, version 2.1.0 would be used instead. To resolve this issue, make sure the same settings are used for restore and for subsequent operations such as build or publish. Typically this issue can occur if the RuntimeIdentifier property is set during build or publish but not during restore.

Expected behavior

Produce a self-contained executable in projA\out\projA.exe

projA.exe will start at projA's entry point but it may call code in projB.

Understood that the SCD should use the latest runtime patch available on my machine, which is 2.1.1. This is according to docs on Self-contained deployment runtime roll forward.

Note that if projB's OutputType is changed to Library instead of Exe then the publish succeeds. But we expect that a P2P reference from one Exe to another Exe should also work because in a different build scenario, we may still want to publish projB as a separate self-contained Exe.

Ideally, the shared code could be reorganized into a third Library project which is a dependency to both, but in this case, projA refers directly to projB. Is this supported?

publish in step 5 implicitly restores projA and its dependency projB. projA is treated as a SCD according the command line arguments, but I guess projB somehow does not get the same SelfContained or RuntimeIdentifier flags since its runtime is not rolled forward. I've seen other issues discussing how the RID gets passed through (#9514) but this seems to be a different problem where projB's OutputType as an Exe is significant.

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.301
 Commit:    59524873d6

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.301\

Host (useful for support):
  Version: 2.1.1
  Commit:  6985b9f684

.NET Core SDKs installed:
  2.1.300 [C:\Program Files\dotnet\sdk]
  2.1.301 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

[livarcocc]

cc @dsplaisted to help with a workaround.

[dasMulli]

@dsplaisted @nguerrera Hypothesis: I think an issue here is also that NuGet doesn't use the same property exclusions as project reference builds use.

NuGet does <GetRestoreProjectReferencesTask …ProjectReferences="@(ProjectReference)"> while MSBuild has logic to carefully unset some global properties (PrepareProjectReferences> @(AnnotatedProjects)), including RuntimeIdentifier. I believe that NuGet and MSBuild evaluation will then see a different list of global properties. Is that correct?

[dasMulli]

cc @peterhuene

[dsplaisted]

It looks like this may be the same issue as, or related to, https://github.com/dotnet/sdk/issues/1834

As a workaround, you can try putting the following in the referenced Exe project:

<PropertyGroup>
  <TargetLatestRuntimePatch>true</TargetLatestRuntimePatch>
</PropertyGroup>

(You can also set the property to false if you don't intend to publish that project as self-contained).

[alexzaytsev-newsroomly]

@dsplaisted unfortunately that fix didn't work for me, i am getting:

error NETSDK1031: It is not supported to build or publish a self-contained application without specifying a RuntimeIdentifier.  Please either specify a RuntimeIdentifier or set SelfContained to false. 

If i get diag logs, i can see that runtime identifier has been unset for the dependent exe project :/

[wolszakp]

Any news or workaround in this topic? There is the same behavior for netcoreapp3.1

[livarcocc]

@wolszakp sorry. This is not something we have prioritized at the moment.