Remove conflict resolution from NETStandard.Library package closure

[dsplaisted]

With dotnet/sdk#1052, the .NET SDK will include conflict resolution. The conflict resolution that currently is part of the Microsoft.Packaging.Tools package should be removed from the closure of NETStandard.Library, so they don't conflict (right now the SDK sets a property to disable the conflict resolution from Microsoft.Packaging.Tools, but there are targets with the same name between the two packages that depend on the fact that the SDK targets are evaluated last).

As I understand it, the plan is for there to be a separate NuGet package which will provide the conflict resolution for non-SDK projects targeting .NET Framework. So the non-SDK conflict resolution should be moved there.

[ericstj]

What about supporting conflict resolution on VS 2017 RTM as mentioned here #299 (comment)? Do we care?

[weshaggard]

or for downlevel VS?

[ericstj]

We care about downlevel VS, that remains regardless and is not part of this discussion. This is talking about removing the targets that specifically support the .NET Core SDK: reading assets / writing deps file. The only place those are applicable now is 2017 RTM.

[ericstj]

@davidfowl you mentioned you needed this in #299, can you elaborate on those requirements?

[ericstj]

We'll be removing the support for this (including 2017 RTM) prior to shipping. At that point it will be a requirement to have the SDK updated. @dsplaisted do you have a reccomended way for us to detect the update so that we can have an actionable error/warning message on RTM? I presume that'd be '$(TargetFramework)' != '' or '$(TargetFrameworks)' != '' and '$(DisableHandlePackageFileConflicts)' != 'true' but that would mean you'd need to keep that property around forever. Perhaps you can suggest an alternative property?

[dsplaisted]

We have dotnet/sdk#534 to add a property for this but don't have it yet.

Disabling the logic if TargetFramework or TargetFrameworks is set should work. That wouldn't force us to keep DisableHandlePackageFileConflicts forever, as far as I understand, as SDK projects would already have one of the other properties set that would disable the logic from your package.

[ericstj]

Disabling the logic if TargetFramework or TargetFrameworks is set should work.

That doesn't work completely because it would cause folks using 1.0 SDK to just fail in unexpected ways (with the conflicts). I'd really like to force an error here.

[dsplaisted]

It would be nice to force a helpful error, but I think you'll get other errors before the targets in the package would have a chance to generate one:

• The 1.0 SDK will not implicitly reference a 2.x version of the NETStandard.Library.
• If the right package is referenced, the version of NuGet in the 1.0 SDK may not successfully restore it (because it doesn't know about the new TFMs, for example)