Question: What does Microsoft.NetCore.Targets actually do?

[czdietrich]

I would like to get some information about what this package actually does, how it works and when I do I need to add it to my projects. I didn't find any useful information about it.

We added this package some time ago when migrating over to .NET Core. It was suggested in some blog post to get rid of warnings when building the solution.
Just to get a better understanding what is going on, some more information would be nice, since the package is more or less just empty.

Thank you in advance.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[huoyaoyuan]

Viewing its content, it only provides runtimes.json on older versions. It does nothing on 5.0.0.

It should be used by some toolchain internally, but not directly.

[czdietrich]

Thank you for your response.

Might it be your answer refers to Microsoft.NetCore.Platforms instead of Microsoft.NetCore.Targets?

[huoyaoyuan]

I'm referring to Microsoft.NetCore.Targets. I viewed their content of each version in my nuget cache folder.

[czdietrich]

Yes, you are right. I did not mention any version. I only checked 3.0.0 and 3.1.0 and those versions do not contain any runtime.json, but e.g. 1.1.3 does.

Nevertheless this doesn't seem to be the whole story of this package, since even without runtime.json it has influence on the build process and fixes NU1605.

[danmoseley]

@joperezr may know

[joperezr]

On earlier versions of .NET Core we used to ship packages individually and we didn't have the concept of the shared framework that we have today. In order to have those individual packages work correctly in the past, we required a runtime.json that would provide a support mapping for RIDs so that packages would end up with the right implementations depending on the RID they would target. Today, we have shared framework and runtime packs that are RID specific and the few packages that still ship independently (for libraries outside of the shared framework) are now what we call "Fat packages" meaning that they should mostly include all of the different RID implementations within its contents. That is why MIcrosoft.NETCore.Targets is less relevant now and doesn't need to provide a runtime.json. As to why do we still build it, that's a good question that perhaps @ericstj might be able to answer, but I'd imagine it is so that if you start referencing a package that would bring in the old closure with the old version of targets but you were targetting a new framework, we will lift this up to the new version of Microsoft.NetCore.Targets that doesn't have a json anymore.

[ericstj]

I'd imagine it is so that if you start referencing a package that would bring in the old closure with the old version of targets but you were targetting a new framework, we will lift this up to the new version of Microsoft.NetCore.Targets that doesn't have a json anymore.

Exactly, we build this new version so that it can replace any references to the old version and stop you from downloading and restoring those old runtime-specific packages which will all be ignored since they're superseded by the shared framework.

[czdietrich]

Thank you for the great insight in how runtime specific dependencies were handled in older versions of .NET Core.

So does it mean I can remove the reference to this package as soon as the whole dependency graph no longer references an old package that still contains runtime.json?

[joperezr]

If you are targeting .NET 3+ already, I believe you shouldn't need to reference this at all to begin with (I may be wrong as I haven't verified) but I believe that if somebody is bringing in an old version of of the package, the shared framework will lift the reference on its own removing the runtime.json. Have you tried removing it from your project and see if that works?

[ericstj]

I don't believe the SDK ever did the work to auto-reference Microsoft.NETCore.Targets cc @dsplaisted

Referencing the package saves NuGet and MSBuild from doing the additional work of downloading only to drop the contents of the old packages. There are some rare circumstances where NuGet will flag a downgrade and this package is required to resolve it: NuGet/Home#3541. If you're not hitting that then you can remove the package, as @joperezr mentions. That said, there is also little harm in keeping it and it will save some restore/build time in the cases it is actually used. You don't need to bother persisting the reference if you're building a package.

[MichaeIDietrich]

I hit exactly the problem you mentioned with the package downgrade. And I added the package in version 3.1 as the recommended solution from here.
I just was wondering, how this packages fixes the downgrade issue without containing any noteworthy files (no runtime.json either). That was the reason I created this issue, since I could not come up with how this package can effect the build graph.

[dsplaisted]

The downgrade problem was related to an older version of the Microsoft.NETCore.Targets package being brought in via transitive dependencies. The older version had a runtime.json which caused package downgrades. So referencing the newer version takes that runtime.json out of the picture and fixes the problem.