Package validation does not report any compatibility errors if package name != assembly name

[Alex-Sob]

Hi team,

We're migrating our existing backward compatibility NuGet package to package validation feature introduced in .NET 6 SDK (baseline version validation).
It works fine in one repo, but we found out it didn't work in another repo - build is not reporting any compatibility errors. I had to do a pretty tough investigation that involved digging into SDK code and creating a test app referencing SDK assemblies, and finally I found out that RunPackageValidation target expects the same package and assembly names:

sdk/src/Compatibility/Microsoft.DotNet.PackageValidation/NupkgParser.cs

Line 47 in 209d138

return new Package(packageId, version, packageReader.GetFiles()?.Where(t => t.EndsWith(packageId + ".dll")), packageDependencies, runtimeGraph);

So, if PackageId and AssemblyName are different in the project file, package validation will not report any compatibility errors and build will succeed.

[ericstj]

This may be a duplicate of #23393. We should consider a fix in servicing to address this.

[safern]

Working on these issues now to get a fix for 6.0.3.

[safern]

Working on these issues now to get a fix for 6.0.3.

[iedeny]

Working on these issues now to get a fix for 6.0.3.

@safern what is a release timeline for 6.0.3?

[claudiamurialdo]

@safern .NET 6.0.3 was released two days ago but this error seems to continue happening. Do you have any idea when it is going to be fixed?

[safern]

@claudiamurialdo sorry for not giving an update, it slipped through. Unfortunately I was not able to make the fix on time for 6.0.3 and I have switched teams inside MSFT (not part of .NET anymore), so I don't think I will be able to take a look at this any time soon. So perhaps @joperezr or @ericstj can take over this one.

The fix that I was planning is simple, it is basically flowing AssemblyName MSBuild property to ValidatePackage task here.

Then update this line:

sdk/src/Compatibility/Microsoft.DotNet.PackageValidation/NupkgParser.cs

Line 47 in 8cfa52e

return new Package(packageId, version, packageReader.GetFiles()?.Where(t => t.EndsWith(packageId + ".dll")), packageDependencies, runtimeGraph);

To use that assemblyName to select the assembly rather than packageId:

return new Package(packageId, version, packageReader.GetFiles()?.Where(t => t.EndsWith(assemblyName + ".dll")), packageDependencies, runtimeGraph);

And flow the AssemblyName to CreatePackage. This is a workaround for 6.0 as for 7.0 or later (I don't know the .NET timeline for this anymore) Package Validation should support loading any assembly within the package regardless of the name and even multiple assemblies.

[PainElemental]

Any news about when the fix will be available?

[joperezr]

The fix has been merged into 6.0.3xx branch in the SDK so it will ship as part of the SDK once 6.0.3xx ships. If the fix is needed sooner than that, we also have a prerelease package that is pushed to one of our public NuGet feeds, so if that is desired, please let me know and I can provide instructions on how to restore it from there.

[PainElemental]

@joperezr Can you give a rough guess when this will be released?

Instructions on how to use the prerelease package would also be cool! Can you post instructions please?

[joperezr]

Unless I'm mistaken, I believe 6.0.3xx SDK should ship along 6.0.5 release, which should be shipping on the first couple of weeks of May.

If you want to use the prerelease package, then you can do so by connecting to our dotnet6 feed and getting the latest Microsoft.DotNet.Compatibility package (which as of now, it's 1.1.0-preview.22210.6). That link I shared has instructions on how to connect to this feed, but basically what you want is to make sure to include the following feed in your NuGet.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    ...
    <add key="dotnet6" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet6/nuget/v3/index.json" />
  </packageSources>
</configuration>

[marcpopMSFT]

Per above, it sounds like this was already fixed in 6.0.300 a few months back so closing.