[Package Validation] Baseline package validation should run with references

[safern]

Currently we are running API Compat without references, causing typeforwards to not be resolved or some other rules might be limited by this.

cc: @ericstj @Anipik

[Anipik]

@safern do we have that support available in api compat ?

[safern]

@safern do we have that support available in api compat ?

Yes we do. You just specify, resolveAssemblyReferences to true when creating the AssemblySymbolLoader:

sdk/src/Compatibility/Microsoft.DotNet.ApiCompatibility/AssemblySymbolLoader.cs

Line 30 in faf81a5

public AssemblySymbolLoader(bool resolveAssemblyReferences = false)

And then you can specify search directories for the loader to find references on:

sdk/src/Compatibility/Microsoft.DotNet.ApiCompatibility/AssemblySymbolLoader.cs

Line 43 in faf81a5

public void AddReferenceSearchDirectories(string paths) => AddReferenceSearchDirectories(SplitPaths(paths));

sdk/src/Compatibility/Microsoft.DotNet.ApiCompatibility/AssemblySymbolLoader.cs

Line 50 in faf81a5

public void AddReferenceSearchDirectories(IEnumerable<string> paths)

You can look at HasLoadWarnings to know if a reference was not found:

sdk/src/Compatibility/Microsoft.DotNet.ApiCompatibility/AssemblySymbolLoader.cs

Line 78 in faf81a5

public bool HasLoadWarnings(out IEnumerable<string> warnings)

[ViktorHofer]

@safern should this issue and dotnet/runtime#56823 be closed now?

[safern]

@ViktorHofer this is partially fixed. The reason why we left this open is because we need to enable running references for baseline validation, we will be doing that for .NET 7. As for the dotnet/runtime issue let me scan the suppression files.

[ViktorHofer]

@ericstj do you remember what the plan was for retrieving and passing in references for baseline packages?

[ericstj]

My suggestion in the past was just to use the current set of references as an approximation. It's not perfect and it can miss breaking changes in the references, but those are not really the things under test.

Fetching the real references for a past packages correctly would require a whole separate restore + resolve references as an isolated project. I don't see this as a practical tradeoff we'd make for the common case. I think we should permit it at the task level if someone wanted to do this themselves (for instance by having a separate project and writing some targets) but in the default case I think we can just get by using existing references as an approximation.