[Bug]: NuGet.Indexing NuGet package should be compatible with net6.0

[KirillOsenkov]

NuGet Product Used

dotnet.exe, MSBuild.exe, NuGet.exe

Product Version

https://www.nuget.org/packages/NuGet.Indexing/6.0.0

Worked before?

No response

Impact

It's more difficult to complete my work

Repro Steps & Context

This NuGet package doesn't properly work when targeting net6.0.
https://www.nuget.org/packages/NuGet.Indexing/6.0.0

We get this warning:

Package 'NuGet.Indexing 6.0.0-rc.262' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework 'net6.0-macos12.0'. This package may not be fully compatible with your project.

and the dependency on Lucene.Net is ignored, Lucene.Net.dll is not copied to output. This is because the dependencies are only declared for net472:

Verbose Logs

No response

[KirillOsenkov]

@sandyarmstrong brings up a valid point that this may be a more general problem than just a single package that wasn't authored for net6.

If we reference Lucene.Net 3.0.3 directly from the project, it works fine, but it is silently dropped as an indirect dependency. This behavior seems suspicious (a bug?)

@nkolev92

[sandyarmstrong]

Right. Basically, if I have a net6.0 app, and I reference a net472 package, nuget is giving me a reference to its net472 assembly. So why not continue down the net472 dependency chain?

Certainly a warning would be appropriate but it seems like when trying to reference a package from another target framework, you should get everything or nothing.

[nkolev92]

Yeah, the bug is #5957.

It's a long standing bug that I've been wanting to fix for a while.
Really hoping to get to it soon.

Setting expectations, NuGet.Indexing adding explicit support for net6.0 is probably not something that is likely to be high on our priority list.

[KirillOsenkov]

Yeah, we've worked around this particular issue by explicitly referencing Lucene.Net, so we're not blocked, but we're hitting this scenario all over the place for other packages, so please focus on fixing #5957. Glad it's known! Thanks!

[nkolev92]

Made good progress in the linked issue: #5957 (comment).

I got to work on this in the context of our Customer Sprint, in which we get to spend time on specific high voted bugs.