Strong name the Chill DLL

[logiclrd]

I have been working on contributions to FluentAssertions, one of which is an internal type that I want to write a unit test for. But, the FluentAssertions DLL is strong-named while its unit test project FluentAssertions.Specs is not. This causes problems, because it isn't possible to use the [assembly: InternalsVisibleTo] attribute to expose the internals of a strong-named assembly to one that is not. When investigating whether I could simply make FluentAssertions.Specs strong-named as well, I bumped into its dependency on Chill, which is itself not strong named.

This PR:

• Autogenerates strongname.snk
• Configures Chill.csproj to use it to sign the build output

I don't have a great deal of experience with this, but I think this means that a Chill published with this change can then be referenced from another assembly that is itself strong named, which unblocks the ability to unit test internal types in FluentAssertions.

Is there any way in which this could cause problems in other areas?

[dennisdoomen]

It did not work.

[logiclrd]

Oh, dear. I should have done that extra level of check. Whoops :-P

[logiclrd]

Huh, so, when I hit Build in Visual Studio, it does get strong-named. I guess that's not how official builds are made :-P

[dennisdoomen]

No, it's the build.ps1 that does all the real work.

[logiclrd]

Yeah. I'm confused, though -- FluentAssertions has the same entries in its .csproj and its Nuke build "Compile" target looks almost identical. Why does FluentAssertions get strong-named and not Chill? 🤔

[logiclrd]

Hmm, so, when I run build.ps1, it puts strong-named files into Src\Chill\bin, but different files, unsigned, into artifacts.

[logiclrd]

What exactly is ILRepack? Why is it doing it? I think that's where the strong name is getting lost.

[logiclrd]

I think I got it. :-)

[logiclrd]

If this gets merged and published, then I believe I will then be able to add unit tests for ObjectReference in FluentAssertions, which unblocks reworking CyclicReferenceDetector to just use a HashSet, which is the one outstanding item presently on its PR 1434. :-)

[dennisdoomen]

I've just published 4.1 to nuget