Skip to content

Packing a .NET Core Exe shouldn't include package dependency on Microsoft.NETCore.App #2204

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

Closed
dsplaisted opened this issue May 1, 2018 · 8 comments
Assignees
Milestone

Comments

@dsplaisted
Copy link
Member

Today, if you pack an Exe project that targets netcoreapp2.0 or higher, the resulting package has a dependency on Microsoft.NETCore.App. If you pack a library, you don't get the dependency in the package.

I think the dependency is included for Exes to support project tools. However, we would like to reconsider this default.

See dotnet/msbuild#3228 where it's causing issues with prodcon and MSBuild.

@dsplaisted dsplaisted added this to the 2.1.4xx milestone May 1, 2018
@dsplaisted
Copy link
Member Author

@nguerrera
Copy link
Contributor

nguerrera commented May 1, 2018

Documenting the workaround. Set PrivateAssets="All" metadata on the Microsoft.NETCore.App PackageReference:

<ItemGroup>
  <PackageReference Update="Microsoft.NETCore.App" PrivateAssets="All" />
</ItemGroup>

@Petermarcu
Copy link
Member

Correct, nothing should have an explicit reference to netcoreapp's package. That should be the default and we should tell people that need it that they should add the reference even though nobody should need to.

AndyGerlicher added a commit to AndyGerlicher/msbuild that referenced this issue May 2, 2018
This dependency should not leak into our NuGet packages. This was added
as the result of a bug (see dotnet/sdk#2204)
and causes issues like the ones listed in dotnet#3228.
AndyGerlicher added a commit to dotnet/msbuild that referenced this issue May 2, 2018
This dependency should not leak into our NuGet packages. This was added
as the result of a bug (see dotnet/sdk#2204)
and causes issues like the ones listed in #3228.
rainersigwald added a commit to rainersigwald/msbuild that referenced this issue May 3, 2018
We took an explicit dependency on Microsoft.NETCore.App in e735b93 to
ensure that we would reference final/stabilized versions of the package
without having to commit a change ourselves. But the NuGet reference to
that package isn't required; listing it was dotnet/sdk#2204.

This commit returns to referencing Microsoft.NETCore.App implicitly,
and includes a workaround to keep its version from affecting our
output packages.
rainersigwald added a commit to dotnet/msbuild that referenced this issue May 3, 2018
We took an explicit dependency on Microsoft.NETCore.App in e735b93 to
ensure that we would reference final/stabilized versions of the package
without having to commit a change ourselves. But the NuGet reference to
that package isn't required; listing it was dotnet/sdk#2204.

This commit returns to referencing Microsoft.NETCore.App implicitly,
and includes a workaround to keep its version from affecting our
output packages.
@livarcocc livarcocc modified the milestones: 2.1.4xx, 2.2.1xx Jun 28, 2018
@dsplaisted
Copy link
Member Author

@wli3, would you like to pick this up? The implicit reference to Microsoft.NETCore.App should have PrivateAssets=All unless the PackageType property is set to DotnetCliTool.

@KathleenDollard We should communicate this as a breaking change for DotnetCliTools that don't set the PackageType property. Given the prevalence of issues that would be fixed by the change and the fact that there is a workaround (set the property) for the breaking change, I think it's worth doing.

@wli3
Copy link

wli3 commented Jul 12, 2018

@dsplaisted will this cause the similar problem of testing global tools -- Microsoft.NETCore.App won't flow to the other project? Although I don't think so, that project should have its own Microsoft.NETCore.App

@dsplaisted
Copy link
Member Author

If anything, I think this could fix issues testing global tools. We may have fixed it in another way already for that case though.

@Tadimsky
Copy link

@dsplaisted Is the recommended workaround for now (until 2.2 is ready to install on our CI machines) to do the set it as PrivateAssets?

@Tadimsky
Copy link

Looks like it doesn't work to set PrivateAssets="All":

9>C:\Users\joschm\Intentional\services\src\Tests\ContentServiceFrontend.Tests\ContentServiceFrontend.Tests.csproj : error NU1605: Detected package downgrade: Microsoft.NETCore.App from 2.1.2 to 2.1.0. Reference the package directly from the project to select a different version. 
9>C:\Users\joschm\Intentional\services\src\Tests\ContentServiceFrontend.Tests\ContentServiceFrontend.Tests.csproj : error NU1605:  ContentServiceFrontend.Tests -> ContentServiceFrontend -> Microsoft.NETCore.App (>= 2.1.2) 
9>C:\Users\joschm\Intentional\services\src\Tests\ContentServiceFrontend.Tests\ContentServiceFrontend.Tests.csproj : error NU1605:  ContentServiceFrontend.Tests -> Microsoft.NETCore.App (>= 2.1.0)

Any ideas?

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

6 participants