-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Comments
Documenting the workaround. Set PrivateAssets="All" metadata on the Microsoft.NETCore.App PackageReference: <ItemGroup>
<PackageReference Update="Microsoft.NETCore.App" PrivateAssets="All" />
</ItemGroup> |
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. |
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.
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.
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.
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.
@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. |
@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 |
If anything, I think this could fix issues testing global tools. We may have fixed it in another way already for that case though. |
@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? |
Looks like it doesn't work to set
Any ideas? |
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.
The text was updated successfully, but these errors were encountered: