Remove package references from library tests

[ericstj]

These tests should be referencing the product assemblies so that they test latest and not old bits.

We should also port this to 9.0. Found this when looking at #106729. None of these caused that issue, but the usage was wrong.

We should only be using PackageReferences to other things which build in dotnet/runtime when we need to reference something not built in the same subset. It must also not need to execute during the build. I wish there was some enforcement for this - right now we just have to try and catch it in code review.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[ViktorHofer]

Won't the P2Ps to BinaryFormatter resolve the NetCoreAppCurrent assembly (PNSE)? We need the NetCoreAppMinimum one (the functioning one). You could add SetTargetFramework=$(NetCoreAppMinimum) to the P2Ps to solve that.

[ericstj]

Won't the P2Ps to BinaryFormatter resolve the NetCoreAppCurrent assembly (PNSE)? We need the NetCoreAppMinimum one (the functioning one). You could add SetTargetFramework=$(NetCoreAppMinimum) to the P2Ps to solve that.

I had suspected to see failures here but didn't. I'll take a look - also see if I can add assertions to force a failure if it breaks.

[adamsitnik]

Won't the P2Ps to BinaryFormatter resolve the NetCoreAppCurrent assembly (PNSE)? We need the NetCoreAppMinimum one (the functioning one). You could add SetTargetFramework=$(NetCoreAppMinimum) to the P2Ps to solve that.

@ViktorHofer Is correct. The tfm trick can be found here:

runtime/src/libraries/System.Runtime.Serialization.Formatters/src/System.Runtime.Serialization.Formatters.csproj

Line 15 in 779baa6

<FunctioningBinaryFormatter Condition="'$(TargetFramework)' == '$(NetCoreAppMinimum)' and '$(DotNetBuildSourceOnly)' != 'true'">true</FunctioningBinaryFormatter>

I had suspected to see failures here but didn't.

All BF tests are marked as conditional. The assembly version is used to determine whether they can be executed:

runtime/src/libraries/Common/tests/TestUtilities/System/PlatformDetection.cs

Lines 739 to 752 in 779baa6

	Assembly assembly = typeof(System.Runtime.Serialization.Formatters.Binary.BinaryFormatter).Assembly;
	AssemblyName name = assembly.GetName();
	Version assemblyVersion = name.Version;
	bool isSupported = true;
	// Version 8.1 is the version in the shared runtime (.NET 9+) that has the type disabled with no config.
	// Assembly versions beyond 8.1 are the fully functional version from NuGet.
	// Assembly versions before 8.1 probably won't be encountered, since that's the past.
	if (assemblyVersion.Major == 8 && assemblyVersion.Minor == 1)
	{
	isSupported = false;
	}

Personally I was using the number of skipped tests as an indicator whether they are actually being run.

[ericstj]

@adamsitnik would it be OK if I removed the use of IsBinaryFormatterSupported in every project where we specifically want to test the behavior with a functioning BinaryFormatter? That will make sure this doesn't regress in the future.

[ericstj]

@adamsitnik would it be OK if I removed the use of IsBinaryFormatterSupported in every project where we specifically want to test the behavior with a functioning BinaryFormatter? That will make sure this doesn't regress in the future.

I gave this a try, but then realized that property is doing double duty. It's also covering cases where the platform doesn't support it, and it predates the removal:

runtime/src/libraries/System.Resources.Extensions/tests/BinaryResourceWriterUnitTest.cs

Line 307 in d40f32d

[ConditionalFact(typeof(PlatformDetection), nameof(PlatformDetection.IsBinaryFormatterSupported))]

runtime/src/libraries/Common/tests/TestUtilities/System/PlatformDetection.cs

Line 121 in d40f32d

public static bool IsBinaryFormatterSupported => IsNotMobile && !IsNativeAot;

So I'll not make this change now, but I do think it would good to separate that state to avoid accidental regression. Make it clear in the test source when you expect to have an actual implementation vs not.

[adamsitnik]

I do think it would good to separate that state to avoid accidental regression.

I agree. I have an idea how it should look like with your changes, let me take a quick stab at it.

[adamsitnik]

#106858 I have tested it locally for Windows and it works as expected. I don't have more time today because I've just logged it to take a day off, will get back to it on Monday (if further changes are required).