Don't include base FrameworkReferences when creating NuGet packages #3102
Conversation
| @@ -46,7 +46,7 @@ Copyright (c) .NET Foundation. All rights reserved. | |||
| Publish="true" /> | |||
| </ItemGroup> | |||
| <ItemGroup Condition=" '$(DisableImplicitFrameworkReferences)' != 'true' and '$(TargetFrameworkIdentifier)' == '.NETStandard' And '$(_TargetFrameworkVersionWithoutV)' >= '2.1'"> | |||
| <FrameworkReference Include="NETStandard.Library" IsImplicitlyDefined="true" /> | |||
| <FrameworkReference Include="NETStandard.Library" IsImplicitlyDefined="true" Pack="false"/> | |||
There was a problem hiding this comment.
Is this a new FrameworkReference?
What does it mean compared to the rest of the frameworks?
There was a problem hiding this comment.
We're (going to be) using a targeting pack for .NET Standard, so the FrameworkReference is how we bring that in.
With Pack=false I think this should not affect NuGet or NuGet packages (just like the base Microsoft.NETCore.App FrameworkReference will be handled).
Basically, FrameworkReferences which are represented by a target framework moniker should have Pack=false and not be represented in NuGet packages or flow transitively. Does Pack=false have this behavior with the FrameworkReference work?
There was a problem hiding this comment.
The last part is new to me.
Restore does not account for Pack=false. It flows everything by default.
Basically the way it's currently working is targeted more for the optional shared frameworks.
Do we need to reconsider that? Do we need to add a PrivateAssets like switch to FrameworkReference items?
There was a problem hiding this comment.
@nkolev92 Yes, we need to be able to prevent the NETStandard.Library FrameworkReference from flowing. Does Pack=false prevent it from being added to the NuGet package? To me it would make sense if that also prevented it from flowing through the projects, but we can also add a PrivateAssets-type flag to it if need be.
There was a problem hiding this comment.
Restore does not read the "pack" attribute and it probably shouldn't.
pack=false will prevent it from being included in the package only.
We should discuss this in a separate meeting or a Monday sync-up.
The existence of a netstandard framework reference also kills our transitivity with FrameworkReference story.
We need to rethink that as well.
Issue: NuGet/Home#7988
//cc @rrelyea
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
….6 (dotnet#3102) - Microsoft.DotNet.Cli.Runtime - 3.1.100-preview1.19505.6
Per comment from @nkolev92: