[NuGet.org Bug]: Code Fixer (analyzer) nuget packages don't have framework metadata

[jzabroski]

Impact

It bothers me. A fix would be nice

Describe the bug

Project-level code analysis and code fixers don't have framework target metadata provided on nuget.org

Repro Steps

1. Go to https://www.nuget.org/packages/AsyncFixer
2. See screenshot below, which says "There are no supported framework assets in this package."

Expected Behavior

Code analysis packages likely have both an expected Framework to target and language version number. At least supporting Framework details would be a good first start.

Screenshots

Additional Context and logs

Related theme to #9015 and #9081 but most likely not the same exact bug

[joelverhagen]

I believe this particular issue is happening because it has no recognized assets. I am not familiar with analyzer packages. I don't see any package type on this package so it would be challenging to disable or populate the Frameworks tab unless we make some analyzer specific logic.

[jzabroski]

Who at Microsoft gets to decide what a package is other than a zip file? I just think that's a basic problem that there is no structure or review process.

[joelverhagen]

Who at Microsoft gets to decide what a package is other than a zip file? I just think that's a basic problem that there is no structure or review process.

I agree, that is a problem for NuGet.org. In general we have been very permissive with what is accepted and only really deal with edge cases on... a case by base basis :). For the Frameworks tab, it's showing the cracks a lot. But I'll not that this does indicate NuGet Restore will behave strangely. I believe Restore will consider this package compatible with every project target framework.

I can say that I used any and every opportunity I have to encourage new NuGet package uses to mark their metadata with package types. These conversations typically only happen internally at Microsoft -- a team comes to us with a NuGet idea. There is no formal process for what constitutes a ".nupkg". In the end it is a ZIP with a .nuspec and anyone can pack .nupkg files however they want using official or unofficial tooling.

Package types are the best tool we have to declare that a package is not your typical dependency package. Unfortunately, many of these edge cases happen to work well enough with NuGet tooling that it's not until much later do folks realize that some features fall over on their packages. Also, some of these edge cases predated package type metadata so it's a moot point there.

Anyways, thank you for reporting this issue. We'll discuss it internally and update the issue when we have planned next steps.

[jzabroski]

I believe Restore will consider this package compatible with every project target framework.

I hypothesize whether restore works at all depends on many hidden pieces, like flags that control the relative paths within the nupkg zip file, such as AppendTargetFrameworkToOutputPath=True|False. To be honest, I've been helping people debug nuget restore issues for years, and only recently discovered the hacky buildTransitive metadata in .nupkg(s) was the glue holding everything together.

I agree, that is a problem for NuGet.org.

No, it's a problem further up the chain of command, IMHO. Very high level people should be aware that teams at Microsoft have no structure around their strategy for sharing code. It's worse than COM Hell.

To be honest, package metadata is really about coming up with an intentional naming system for resources. Which is actually a pretty hard problem, especially when you allow wild cards (aka "starnames"), because you also have to make sure operations are transitively monotonic under addition. - Some wild card systems are better than others. Nuget does one thing arguably right which is it defaults to the lowest possible transitive dependency. However, netstandard is fundamentally a hidden starname.

[joelverhagen]

For the more general issues you have about package metadata ambiguities, I think it might make sense to move that part of the conversation to either a discussion on NuGet/Home or (if you have some specific direction you think makes sense) a proposal.

For the specific framework tab behavior, we'll keep this issue open to track that gap.