Add PackageReference metadata #217
Conversation
src/Ionide.ProjInfo/Types.fs
Outdated
| FullPath: string | ||
| /// See e.g. https://github.com/dotnet/sdk/blob/6ef345b1ff76eec2de6a0deeda321cae45da655b/src/Tasks/Common/MetadataKeys.cs#L65 | ||
| /// for a large set of keys which may or may not be present in this metadata dict. |
There was a problem hiding this comment.
(This all seems to be completely undocumented and frankly quite terrifying.)
There was a problem hiding this comment.
It's not undocumented, it's just that MSBuild is an open system and any single piece of MSBuild logic can add or interpret metadata on MSBuild Items however it wishes.
As a result, certain patterns and well known metadata keys (ideally documented) become the contracts.
For example, here's the metadata that MSbuild gives you for any Item: https://learn.microsoft.com/en-us/visualstudio/msbuild/msbuild-well-known-item-metadata?view=vs-2022
There was a problem hiding this comment.
Generally, if a specific piece of metadata is required, e.g. TargetPath, you'd make a Task who's job it is to take Items as input and add TargetPath metadata to all of the items. Then you'd put that Task in a Target so that folks have a publicly-visible way to ensure that a given group of Items gets that metadata.
There was a problem hiding this comment.
Thanks; sounds like it's finally time for me to read the MSBuild docs end-to-end :(
In that case I will not attempt to document the metadata field.
|
Some of this metadata is pretty amusing for PackageReferences. A |
What you're seeing is the legacy code part of MSBuild and it's implications 😅 Originally in MSBuild, only Files could be Items. So any Item you made it was very likely you were going to be doing file-ish operations on, so the engine helpfully computes all of these properties that are relevant for files. In the great cross-platforming and simplification of .NET, the Item concept was extended to mean 'any kind of identifier with associated metadata' - but the engine itself wasn't really changed to provide any kind of semantic distinctions between 'this thing is a file' and 'this thing is a property bag that I expect to have a shape like BLAH'. As a result, all Items now have these legacy metadata! Migrating from this in a compatible way is one of the big hurdles we like to address in the engine, but it's a big lift because you're basically talking about retrofitting a type system onto an untyped space. |
|
OK, this looks like a bit of a can of worms and I can do the munging I need in MsBuild XML land, so I'll close this. |
I would like my Myriad-like source generator system to be able to see the line
<PackageReference Include="MyCoolPlugin" WhippetPlugin="true" PrivateAssets="all" />. That is, I would like "register this plugin with Whippet" to be as simple as "addWhippetPlugin="true"to the NuGet import". To do that, I need access to the package metadata.I have made no attempt to filter out any metadata which has already been stored somewhere. In practice, these dictionaries seem to be fewer than 10 elements big.
Whitespace changes are the result of
dotnet fantomas ..I've checked after merging #216 that all the information I require is now present in the
PackageReferenceoutput list.