Add package id and version to Reference and ReferenceCopyLocalPaths Items #603
Conversation
| { | ||
| throw new BuildErrorException(Strings.ContentFileDoesNotContainExpectedParentPackageInformation, contentFile.ItemSpec); | ||
| } | ||
| string packageName = parts[0], packageVersion = parts[1]; |
There was a problem hiding this comment.
(nit) I think it is uncommon to make assignments like this in our current code base. Can these be split into 2 lines?
| @@ -296,6 +298,8 @@ Copyright (c) .NET Foundation. All rights reserved. | |||
| <Private>false</Private> | |||
| <NuGetIsFrameworkReference>true</NuGetIsFrameworkReference> | |||
| <NuGetSourceType>Package</NuGetSourceType> | |||
| <NuGetPackageId>%(_FrameworkAssemblies.PackageName)</NuGetPackageId> | |||
There was a problem hiding this comment.
Question for my understanding (no change necessary): Why the difference in metadata names here? NuGetPackageXXX vs. just PackageXXX? Why is one prefixed with NuGet and the other isn't?
It is my understanding that this change is needed for .NET Core 2.0 scenarios. |
| @@ -280,6 +280,8 @@ Copyright (c) .NET Foundation. All rights reserved. | |||
| <Private>false</Private> | |||
There was a problem hiding this comment.
existing: why use batching here instead of a transform? If you use @(_CompileFileDefinitions->'%(ResolvedPath)') it will preserve all the meta-data and you don't need to do things like
+ <NuGetPackageId>%(_CompileFileDefinitions.PackageName)</NuGetPackageId>
+ <NuGetPackageVersion>%(_CompileFileDefinitions.PackageVersion)</NuGetPackageVersion>
|
Tagging @MattGertz for RTM approval. |
|
Needs template -- I'm not clear on this v.v. the Escrow bar. |
… in metadata for compile files and framework assemblies
|
Retarget to master after #917 goes in |
|
/cc @nguerrera @dsplaisted for one more review before I merge |
…ableProject Set WarnOnPackingNonPackableProject to true when IsPackable is false
Fixes #567
This adds
NuGetPackageIdandNuGetPackageVersionmetadata toReferenceandReferenceCopyLocalPathsItems. These are used downstream by a few tasks.This leads to additional metadata on a few definitions from the ResolvePackageDependencies and ProduceContentAssets tasks, which matches the old ResolveNuGetPackageAssets task, but I'm not sure if there are significant MSBuild performance implications.
Also not sure if we would take this for escrow as these are not .NET Core scenarios, but making this solution available to unblock downstream work.
/cc @ericstj @srivatsn @nguerrera @dsplaisted