Skip to content

Runtime identifier is not forwarded when publishing exe project references (self-contained mode) #16184

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

Open
ltrzesniewski opened this issue Mar 3, 2021 · 5 comments
Assignees
Milestone

Comments

@ltrzesniewski
Copy link
Contributor

This is a follow-up to #1675 and #14488. Tested with the SDK v5.0.200.

If you have a project A that references a project B, and both are of the exe output type, then publishing A with a runtime identifier will generate a self-contained A, but a framework-dependent B.

Here's a simple repro:

dotnet new console -o A
dotnet new console -o B
dotnet add A reference B
dotnet publish A -r win-x64

A.deps.json will have the .NETCoreApp,Version=v5.0/win-x64 runtime target, and B.deps.json will have .NETCoreApp,Version=v5.0.

Workaround:

If you change the project reference to the following:

<ProjectReference Include="..\B\B.csproj" SkipGetTargetFrameworkProperties="true" />

Then B will be published in self-contained mode as expected.

/cc @dsplaisted

@ghost ghost added the untriaged Request triage from a team member label Mar 3, 2021
@ghost
Copy link

ghost commented Mar 3, 2021

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@deng0
Copy link

deng0 commented Apr 17, 2021

I've noticed the same problem.

It seems instead of specifying SkipGetTargetFrameworkProperties in A.csproj another workaround is to specify RuntimeIdentifiers in B.csproj. Something like this <RuntimeIdentifiers>win-x64;linux-x64</RuntimeIdentifiers>.
I don't really understand why, but when RuntimeIdentifiers is specified the runtime identifier is forwarded to B.csproj when doing a publish on A.csproj.

It would be nice if someone with a better understanding could elaborate on this.

@CCRcmcpe
Copy link

CCRcmcpe commented Jul 6, 2021

Same, it caused inconvenience when publishing a project that references many other projects.
If you don't want to modify project files like @deng0 mentions, you need to build all the depended projects manually with -r before publishing with --no-build.

@ltrzesniewski
Copy link
Contributor Author

ltrzesniewski commented Jul 14, 2021

I noticed that the SkipGetTargetFrameworkProperties workaround doesn't work with projects that need to generate a publish-specific deps.json file, as of the SDK 5.0.400-preview.21277.10.

In my case, this situation happened because of a PackageReference with PrivateAssets="all".

Here's a different workaround, in case it helps anyone:

<Target Name="AddReferencedExeProjectForPublish" BeforeTargets="CopyFilesToPublishDirectory">
  <MSBuild Projects="..\B\B.csproj" Targets="Publish" Properties="PublishDir=$([System.IO.Path]::GetFullPath($(PublishDir)))" BuildInParallel="$(BuildInParallel)" />
</Target>

It essentially publishes B to the same output path when you want to publish A. Not pretty, but it works.

@marcpopMSFT marcpopMSFT added the needs team triage Requires a full team discussion label Aug 24, 2021
@marcpopMSFT marcpopMSFT modified the milestones: 5.0.3xx, 6.0.2xx Aug 24, 2021
@marcpopMSFT marcpopMSFT removed the needs team triage Requires a full team discussion label Aug 25, 2021
@marcpopMSFT marcpopMSFT modified the milestones: 6.0.2xx, 6.0.3xx Jan 25, 2022
@marcpopMSFT marcpopMSFT modified the milestones: 6.0.3xx, Backlog Mar 30, 2022
@dsplaisted
Copy link
Member

This may be the same as or related to #21677

ViktorHofer pushed a commit that referenced this issue May 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants