Strong name?

[grzesiek-galezowski]

Hi, just wanted to ask - could ConventionTests have a strong name like NUnit, NSubstitute, AutoFixture or Castle.Core?

Having a strong name would allow ConventionTests to be referenced by strongly named assemblies.

[JakeGinnivan]

For strong naming you can use https://github.com/dsplaisted/strongnamer instead. Which allows people using strong name to still work and others to not have the issues associated.

And I don't understand why test projects would ever need to be strong named, do you need to load multiple versions of the same assembly into the same appdomain in your tests?

[grzesiek-galezowski]

The reason is that some people use InternalsVisibleTo in strong assemblies to make internals accessible to a test assembly. In such case, a test assembly needs to be signed as well.

I am evaluating the strong namer approach. I can already see some downsides for my scenario but I'll take a day or two to check whether I can work around them.

[grzesiek-galezowski]

I evaluated the approach of using strong namer and it seems it is not acceptable in my case. Please allow me to describe my use case for convention tests.

1. I develop a library. What I want to do is to distribute with that library a series of conventions. As convention tests has a very limited number of conventions, I consider this use case is not an unusual one.
2. This means that I need to reference convention tests and, at the same time, the developer who uses my library will need to reference it as well (preferably through nuget).
3. I want to support people who use strongly-named production assemblies and InternalsVisibleTo(). Although I am not a fan of InternalsVisibleTo(), I don't want to tell those people to change their approach or go away, especially that even some of the projects where I work use this approach sometimes.
4. If I were to sign my version of convention tests with strong namer, the version they reference in their test projects would need to be signed as well, so they would need to include strong namer in their test assemblies as well. This looks pretty much OK in case where their test assembly needs to be signed anyway (because without the strong namer, they would not be able to use convention tests anyway from strongly-named assembly as it's currently unsigned). The problem is that in such case, non-signed test assemblies would also be forced to include strong namer, only to support a scenario they might never use. This is where, by choosing this approach, I become less user-friendly.
5. Even if I accepted the things I wrote in point 4 and just forced all my clients to include strong namer (with nuget it is a bit easier), I noticed that NCrunch does not play nice with it and basically stops working. Where I work, almost 100 developers use NCrunch daily and I don't want to break a working toolchain for them and any other users that I do not know of.

On the other hand, there are only two downsides of signing an assembly such as convention tests or my own library that I ran into (there are others, but they mostly don't apply to testing libraries):

1. If another assembly exposes internals to it via InternalsVisibleTo(), it has to include a public token and it itself has to be signed - it doesn't seem to be a big deal, since this would apply only to assemblies in your repository (as other assemblies don't seem to have a business in exposing their internals to convention tests), plus I noticed the convention tests code doesn't use InternalsVisibleTo() anyway.
2. The convention tests assembly would not be able to include non-signed dependencies - this is the only serious issue, however:
   a) you don't seem to have many dependencies anyway and signing the assembly didn't break anything when I tried, a) many libraries (including ones for testing) are signed. In my library, I reference AutoFixture, NUnit, NSubstitute, FluentAssertions, Compare.NetObjects, Castle.Core and NClone and all of them already have strong names.

Please consider my use case in favor of signing convention tests.