Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ivanwick opened this issue Jun 22, 2018 · 7 comments
Open
Milestone

Comments

@ivanwick
Copy link

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
Copy link
Contributor

cc @dsplaisted to help with a workaround.

@dasMulli
Copy link
Contributor

dasMulli commented Jun 23, 2018

@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
Copy link
Contributor

cc @peterhuene

@dsplaisted
Copy link
Member

It looks like this may be the same issue as, or related to, #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
Copy link

@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
Copy link

wolszakp commented Dec 27, 2019

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

@livarcocc
Copy link
Contributor

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

@msftgits msftgits transferred this issue from dotnet/cli Jan 31, 2020
@msftgits msftgits added this to the Discussion milestone Jan 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants