Autofixture: Devrions-nous garder notre clé de signe secrète?

Auparavant, @ploeh gardait

Si nous vérifions d'autres assistants de test populaires, nous constaterons qu'ils ont tous ouvert une clé publique :

1. xunit- key est ouvert .
2. nunit- key est ouvert .
3. La clé de substitution N
4. La clé Moq
5. FakeItEasy- key est ouvert .
6. La clé FluentAssertions

Je ne vois pas trop de sens de garder la clé AF fermée et je pense que nous pouvons également l'ajouter au référentiel. En effet, signer permet de prouver l'identité de l'assemblée, mais je ne pense pas que nous l'exigeions strictement. De nos jours, NuGet est utilisé pour distribuer des packages, plutôt que des sites tiers où l'identité compte effectivement.

Si nous publions la clé dans le référentiel, cela aura de nombreux avantages :

1. Il sera plus facile de générer NuGet avec des assemblys signés par CI.
2. Il sera plus facile pour les gens de créer leurs propres assemblages AutoFixture et de tester si cela résout un problème particulier. Considérez le scénario suivant :

1. You found some bug in AF. You download source code locally and fix it.
2. Now you have AF assemblies with fixed bug and you want to test whether it helped.

Here is where the issues start. If you assemblies are unsigned, you cannot simply put the modified assemblies to the local NuGet cache - project will not compile. Rather, you need to update all your projects to target to a new assembly - just for a simple test. The things become even worse when that is the core `AutoFixture` assembly, as other depending libraries (like `AutoFixture.xunit` or `AutoFixture.NSubstitute`) will need to be updated as well.

If we ship signing key issue will be solved.

1. Vous n'avez pas besoin de stocker un secret de plus :)

Quant au @ploeh , il semble qu'il n'avait pas de bonnes raisons de le garder secret.

Personnellement, je voterais à deux mains pour ouvrir la clé et simplifier la vie de tous.
Les gars ( @moodmosaic , @adamchester , @ecampidoglio , @klimisa) - qu'en pensez-vous ?