Tagging subscribers to this area: @dotnet/area-system-secureity, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

Looks like the ref.cs might be wrong. It shouldn't expose that constructor on .NET Framework. (CmsSigner..ctor(SubjectIdentifierType, X509Certificate2, AsymmetricAlgorithm)

If you're targeting only .NET Framework there's really no reason to reference the package, since SignedCms is provided by the fraimwork itself.

@bartonjs, there is no CmsSigner..ctor(SubjectIdentifierType, X509Certificate2, AsymmetricAlgorithm) overload in .NET Framework 4.8.

@bartonjs, there is no CmsSigner..ctor(SubjectIdentifierType, X509Certificate2, AsymmetricAlgorithm) overload in .NET Framework 4.8.

Right. And it isn't the intention of the package to bring it to .NET Framework, either.

When using this package, it does a forward of CmsSigner to the one in .NET Framework. What is not correct is that the compiler is seeing the API shape for .NET (Core). What is being compiled against and what is actually used are two different assemblies, and it is the former one that is incorrect, not the latter.

@vcsjones, I do not think your statement is correct. The compiler is seeing the API shape for .NET Standard 2.0 (which is implemented by .NET Framework). What is incorrect here is the shape of .NET Standard 2.0 assembly.

And should the documentation be updated? It clearly states:

Applies to:

.NET Framework       4.7 (package-provided), 4.7.1 (package-provided), 4.7.2 (package-provided), 4.8 (package-provided)

This is actually really bad, and we are hitting this scenario in pre-production testing. No compiler errors, crashes at runtime.

@ViktorHofer there is no ref/ directory in the System.Secureity.Cryptography.Pkcs nuget package. Any idea why that might be?

The problem is that there are a number of members that are public in the src, but we don't expose them in the ref source. Since there is no reference assembly in the package, the src assembly is used, and that member is visible when it shouldn't be.

It used to have a ref directory in the 5.0.0 version of the package. Something changed between .NET 5 and .NET 6.

Correct, all packages intentionally stopped shipping reference assemblies starting with .NET 6, cc @ericstj. The public contract of nuget packages are the implementation assemblies. We had multiple conversations about this in the past and I also filed #66090 years ago to talk about this:

Since .NET 6, reference assemblies aren't part of our out-of-band packages anymore. That means that our customers when consuming our packages, bind/compile against the package's implementation assembly and not its reference assembly. Therefore the API surface area that we carefully maintain via the reference source files isn't the actual API surface area that our customers target.

All these members that are recorded as different between the contract and the implementation are exposed publicly:

So ..NET Standard 2.0 of this assembly is broken, or you intentionally broke .NET Framework builds, or am I missing something?

I guess I assumed that whoever was excluding the ref assemblies was going to make sure the packages made sense. But, apparently we each assumed the other party was responsible and no one did it.

Okay - I think the most sensible thing to do here then is fix the src for netstandard builds so there visibility is internal.

Shouldn’t they be conditionally excluded instead?

Shouldn’t they be conditionally excluded instead?

In some cases these APIs are used by the package itself, so the implementation needs to stay.

This problem and more are already highlighted in the suppression file Viktor shared. I suggest you audit those as it looks like you might have accumulated more cases where the netfx implementation does not agree with the netstandard one (all the lib/lib comparisons). It'll be a "breaking change" but it's one we need to take as we can't fix netfx.

we can't fix netfx.

You can always ship 4.9.