Need a way to ignore build configurations when library is inbox

[weshaggard]

For libraries like DirectoryServices which are inbox on a framework (https://github.com/dotnet/corefx/blob/master/src/System.DirectoryServices/pkg/System.DirectoryServices.pkgproj#L10) and only have a netstandard configuration without a netfx configuration because it shares the same identity as desktop, we need a way to tell our build system to ignore the netstandard configuration when building the netfx vertical. Without that we will end up selecting the netstandard asset and building and testing that when doing our netfx vertical testing.

We can probably add a new property called something like IgnoreBuildConfigurations or InboxOnFramework and teach our configuration system (likely somewhere in https://github.com/dotnet/corefx/blob/master/buildvertical.targets#L70) to filter out and skip such configurations.

[safern]

I definitely think we should get this fixed as part of the Compat pack effort to be able to have the tests running against the inbox netfx assemblies and catch differences in behavior. I've started running them locally by manually removing the netstandard assemblies from the runtime and testhost netfx folder so that it is linked to the GAC assembly.

[safern]

This is done. We now can do this and we have done this for all the projects in the Compat pack. We're just missing, System.ComponentModel.Composition which has internalsVisibleTo and a lot of internal testing. Which when testing vs inbox assembly we can't access. I have an issue tracking that: https://github.com/dotnet/corefx/issues/25781

[stephentoub]

@safern, there are ~180 tests with ActiveIssue against this issue.

[safern]

Ok, I'll take a look at why and fix it accordingly.

[ViktorHofer]

ping @safern. Would love to close this again, can you please scan tests and remove/diagnose the active issues?

[safern]

Yeah. I just have had other priorities. I just wrote this down on my pending tasks to not forget. Will get to it in the coming days, thanks.

[ViktorHofer]

@safern I wouldn't spend too much time on this as with #35606 we will stop using the RefPath for anything != NetCoreAppCurrent and I'm considering getting rid of the RuntimePath for OOB libraries
as well and build them app-local instead, which is the way they are being used by customers. I talked about this with @ericstj in the past.

As an example, a .NET Framework Test Library would either use a P2P (to the ref&impl, if the live built assets should be used) or a simple name reference (if the assembly should be resolved from the GAC).