InternalsVisibleTo PublicKey does not respect variables in NET5 Preview SDK

[JimBobSquarePants]

I'm hoping this is the right place, please let me know If I shouldraise the issue elsewhere.

For SDK versions prior to .NET 5 previews it is possible to declare InternalsVisibleTo values in a Directory.Build.props file in subfolders using the following approach.

<InternalsVisibleTo Include="SixLabors.ImageSharp.Web.Tests"  PublicKey="$(SixLaborsPublicKey)" />

Where the variable had been declared in a root Directory.Build.props file.

<SixLaborsPublicKey> KEY HERE </SixLaborsPublicKey>

When attempting to build a solution via dotnet build with any .NET 5 preview SDK installed the folllowing error occurs.

error CS1726: Friend assembly reference 'SixLabors.ImageSharp.Web.Tests' is invalid. Strong-name signed assemblies must specify a public key in their InternalsVisibleTo declarations.

What has changed which breaks current behavior and what (other than disabling the preview via global.json) is the correct workaround?

[davkean]

Can you attach a binlog via the following?

msbuild [project] /binlog:build.binlog

[JimBobSquarePants]

@sandcastle would you be able to provide this? I don't have the latest VS preview installed to support it and have an atrocious internet connection.

[tannergooding]

Reposting what I responded to with on twitter:

The issue is that ImageSharp has its own logic for generating InternalsVisibleTo (https://github.com/SixLabors/ImageSharp/blob/f80a960f1752afcbb707d4274b2b0381d9756bed/src/Directory.Build.targets#L40-L60…) and the .NET 5 SDK added built-in support which is basically the same but which uses Key, rather than PublicKey

So the .NET SDK support ends up conflicting.

[tannergooding]

The SDK version does support PublicKey as well, but as a global property, rather than as metadata attached to an individual IVT: https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.GenerateAssemblyInfo.targets#L108-L112

[JimBobSquarePants]

Thanks for looking into this @tannergooding that's really awesome of you.

So there's a few options...

• We update PublicKey attribute name in our version to use Key
• We update SixLaborsPublicKey global property in our version to PublicKey
• .NET SDK uses a PublicKey consistently across attribute and property names.

In Jamestopia the .NET SDK would use a consistent name but that's so obvious I'm sure I'm missing some subtle reason that precludes that possibility.

[kzu]

The reason is mostly historic. I added that feature following the existing "Arcade SDK" stuff that used that attribute, so that it could be a drop-in replacement for MS teams using that.

In retrospect, it's confusing, and it should have been PublicKey in both places, but that would have broken the Arcade SDK-using folks, and at this point I'm not sure it's worth supporting the two attributes (it's fairly easy to update items to map one to the other too). Dunno...

[ladeak]

I am using .NET 7 preview 5 SDK (7.0.100-preview.5.22307.18). I have strong-named assemblies.

I declare in my csproj:

  <ItemGroup>
    <InternalsVisibleTo Include="MyAssembly.Tests" PublicKey="0024...mykey....8b6"/>
  </ItemGroup>

I get a build error:
Error CS1726 Friend assembly reference 'MyAssembly.Tests' is invalid. Strong-name signed assemblies must specify a public key in their InternalsVisibleTo declarations.

This is what I see in the generated assembly info.

[KalleOlaviNiemitalo]

@ladeak, this fix is not in https://github.com/dotnet/sdk/blob/release/7.0.1xx-preview5/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.GenerateAssemblyInfo.targets, but it is in https://github.com/dotnet/sdk/blob/release/7.0.1xx-preview6/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.GenerateAssemblyInfo.targets:

sdk/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.GenerateAssemblyInfo.targets

Lines 109 to 111 in 18c815b

	<InternalsVisibleTo Condition="'%(InternalsVisibleTo.PublicKey)' != ''">
	<Key>%(InternalsVisibleTo.PublicKey)</Key>
	</InternalsVisibleTo>

[WeihanLi]

Think could be closed?

[KalleOlaviNiemitalo]

Backporting to .NET SDK 6 doesn't seem necessary; any team hitting this problem would have worked around it already.