Intermittent poison test failure: Value is not null

[mthalman]

This failure is still appearing intermittently for the Microsoft.DotNet.SourceBuild.Tests.PoisonTests.VerifyUsage test:

Assert.Null() Failure: Value is not null
Expected: null
Actual:   "\nExpected file '/__w/1/s/artifacts/bin/Microsoft."···

Example build (internal link)

[MichaelSimons]

While the poison leaks were baselined as acceptable, the baseline entries are different based on where the packages are read from - reference packages versus PSB/reference packages. In the former the Type is SourceBuildReferenceAssembly while the later is AssemblyAttribute.

[ViktorHofer]

This (the poison file not being found) regressed with dotnet/dotnet@83f0c72 and will be fixed by dotnet/dotnet#176

[MichaelSimons]

This (the poison file not being found) regressed with dotnet/dotnet@83f0c72 and will be fixed by dotnet/dotnet#176

@ViktorHofer - I think you are referring to the following failure as seen in this build:

System.InvalidOperationException : Poison report '/__w/1/s/artifacts/log/Release/poison-usage.xml' does not exist.

The original issue is about a known poison leak that get's reported differently based on where nuget resolves the package from.

[MichaelSimons]

[Triage] We are looking for a low cost solution to address this allowed poison usage to get green builds. The long term direction is to remove the reference packages from previous source build artifacts.

[NikolaMilosavljevic]

Fixed with dotnet/dotnet#502

[NikolaMilosavljevic]

Reactivating this one as we still see occasional issues with 4 files. This is really odd as all of the files in poison baseline are coming from a single package NETStandard.Library and it is only ever resolved from reference location now.

     <Type>SourceBuildReferenceAssembly</Type>
   </File>
   <File Path="artifacts/assets/Release/Sdk/x.y.z/dotnet-sdk-x.y.z/sdk/x.y.z/ref/mscorlib.dll">
-    <Type>SourceBuildReferenceAssembly</Type>
+    <Type>AssemblyAttribute</Type>
   </File>
   <File Path="artifacts/assets/Release/Sdk/x.y.z/dotnet-sdk-x.y.z/sdk/x.y.z/ref/netstandard.dll">
-    <Type>SourceBuildReferenceAssembly</Type>
+    <Type>AssemblyAttribute</Type>
   </File>
   <File Path="artifacts/packages/Release/Shipping/msbuild/Microsoft.Build.Runtime.x.y.z/contentFiles/any/netx.y/ref/mscorlib.dll">
-    <Type>SourceBuildReferenceAssembly</Type>
+    <Type>AssemblyAttribute</Type>
   </File>
   <File Path="artifacts/packages/Release/Shipping/msbuild/Microsoft.Build.Runtime.x.y.z/contentFiles/any/netx.y/ref/netstandard.dll">
-    <Type>SourceBuildReferenceAssembly</Type>
+    <Type>AssemblyAttribute</Type>
   </File>

[NikolaMilosavljevic]

Very odd - package source mappings are correct for msbuild repo, but the affected package was still resolved from PSB location, which shouldn't be possible:

Installed NETStandard.Library 2.0.3 from /__w/1/s/prereqs/packages/previously-source-built/ to /__w/1/s/src/msbuild/artifacts/.packages/netstandard.library/2.0.3 with content hash mLZsD5fXkALx5DG5/G6Kxf0FlDikLxqHG/tjXShJl5qwK+0+2cAsdZwbxAqdmUOMTLeyD68MGVWm/9O2t73qhQ==.

[NikolaMilosavljevic]

The issue is in malformed NuGet.config file in msbuild repo - packageSourceMapping element is incorrectly placed under packageSources element. This resulted in package source mappings that are never used by Nuget.