Make CoreFx.Private.TestUtilites RID-agnostic

[ViktorHofer]

Changes:

• Downgrade CoreFx.Private.TestUtilities to a "normal" test project and remove its packaging

EDIT: Removed the harvesting part from this PR

[ViktorHofer]

@ericstj is there a way to suppress the mismatch error here? Microsoft.Win32.SystemEvents has mismatched compile (4.0.1.0) and runtime (4.0.0.0) versions on .NETCoreApp,Version=v2.0/win7-x86..

I understand the issue but as we live build the ref which is used for the harvested asset (netcoreapp2.0) that assembly version will always be higher.

[ViktorHofer]

@ericstj I added a netcoreapp2.0 ref live build asset because of an AssemblyVersion mismatch between the lib and ref.

[ViktorHofer]

@ericstj ok this didn't work well. I now pinned the assembly version to 4.0.0.0. Let me know if there's a better approach.

[ericstj]

Let me know if there's a better approach.

Per my above comment don't harvest the lib.

When thinking about these packages you should try to imagine the "meaningful" differences in the libraries. I'd assert that netcoreapp2.0 vs netcoreapp (latest) isn't a meaningful distinction since the library isn't adding new API nor is it trying to make use of new API we've added to the framework. As such you shouldn't harvest the netcoreapp2.0 asset as it is the latest meaningfully significant configuration for the library. Also consider that multiple configurations without meaningful differences should be avoided as it bloats the package.

If you happen to harvest a lib you need to harvest all refs that might apply to the same framework, so if you harvest netcoreapp2.0 you need to make sure you harvest the netcoreapp2.0 ref and netstandard2.0 ref since neither one is allowed to change as it would make the assembly version greater than the harvested one. This could force you to add a desktop configuration for a ref in some case if you are still live building the desktop impl. That said, I don't think you should do any of that here.

[ViktorHofer]

Thanks, that makes perfectly sense. I stopped the netcoreapp2.0 harvesting and will review the pkgprojs when I'm back from holiday.

[ViktorHofer]

As Microsoft.Win32.Registry is still needed in multiple projects that target netfx I followed the same approach that I took for System.Memory and binplaced the harvested assets. I added ProjectExclusions to not build the project anymore (as it still has a netstandard configuration which would be chosen). Unfortunately it seems that the exclusions break the P2P reference from System.IO.Ports to Microsoft.Win32.Registry when System.IO.Ports targets netstandard instead of netfx (see offline mail thread why it does so during a netfx run).

@ericstj thoughts?

[ericstj]

break the P2P reference from System.IO.Ports to Microsoft.Win32.Registry

There is no P2P reference. There is a simple name reference and you stopped producing the 'netstandard' ref for Registry. You either need to ensure you still build that or binplace it. Note that binplacing it may be a problem for source build. https://github.com/dotnet/corefx/issues/36451

[ViktorHofer]

Sorry for mixing up terms, you are right this is just a simple name reference.

I cherry-picked the configuration fix for System.IO.Pipes ef527a1 into this PR and the error is now gone as in the netfx build the netstandard version of System.IO.Pipes isn't build anymore and therefore it doesn't require the netstandard version of Microsoft.Win32.Registry during the netfx vertical build anymore.

[ViktorHofer]

@ericstj I factored out the harvesting changes and this now only deals with CoreFx.Private.TestUtilities. Can you please take a look?

[ericstj]

Looks reasonable. Thanks for pulling out registry changes.

[ViktorHofer]

OK, VS experience now works with the changes :)