Don't pass duplicate items to conflict resolution if CopyLocalLockFileAssemblies is true

[dsplaisted]

Fixes #1135

[dsplaisted]

@dotnet-bot

test OSX10.12 Release
test Windows_NT_FullFramework Debug
test Windows_NT_FullFramework Release

[dsplaisted]

@ericstj for review

[nguerrera]

Today, CopyLocalLockFileAssemblies for netcoreapp include shared framework and don't respect other publish filtering mechanisms either. I think that's what you want here, but I also want to fix CopyLocalLockFileAssemblies to be more like "publish in place". See #933

I'm annoyed by the fact that the log can be filled with items called CopyLocal that are not in fact copied anywhere. I'm not pushing back on this change because we're already in that boat, but it's something that's been on my mind for a while.

[nguerrera]

@livarcocc Did you turn on the "this branch is out-of-date with the base branch" check? I think it does more harm than good. On several occasions, folks have done incorrect merges from release to master after submitting PR straight from release to master and pushing the big button to update release to master! It also adds extra merge commits to the history that we generally don't need. Can we turn it back off please?

[dsplaisted]

@MattGertz for approval

Customer scenario

Build a project targeting .NET Framework which references a NuGet package. Without this fix, there will be errors in the log indicating there is a conflict when there shouldn't be.

Bugs this fixes:

#1135

Workarounds, if any

Ignore log file.

Risk

Low

Performance impact

Low - This will probably improve perf as it will mean the conflict resolver doesn't have to examine as many assemblies.

Is this a regression from a previous update?

It's a regression from the version of conflict resolution that was originally shipped in preview versions of the 2.0 NETStandard.Library package.

Root cause analysis:

A case was missed while moving and refactoring the code.

How was the bug found?

Bug report from @ericstj