All geek questions in one place

InternalsVisibleTo, Signing and Unit tests, how to make it practical?

In "C # in Depth 2nd Edition", John Skeet's book, which I just read before the end of Part 2, is mentioned in 7.7.3 that InternalsVisibleTo can also be used with signed assemblies. At the moment, I have not used signatures at all. The security issue for released binaries is actually quite critical, so I plan to completely remove the attribute for release assemblies using the preprocessor variable test.

Just for fun, how would it make sense to use signed assemblies and InternalsVisibleTo ? To use InternalsVisibleTo to specify a friend's signed assembly, I need to specify its public key. I only have this after compiling a friend’s assembly, which has a dependency on the assembly under test (dynamic assembly and unloading were left out, which would inflate coding and readability). This sounds like a chicken egg problem requiring a bootstrap assembly check. I can imagine some tricks with MSBuild and scripts to automate this. Is there a more practical way to do this?

In case it is so tiring, I will stick to my first idea to abandon Unit Testing to build the release (which is somewhat unsatisfactory, since subtle problems of time can remain unchecked ...)

+4
source share
1 answer

Use the same key to sign all the projects in the solution, do not create different ones for each project and each assembly. I would recommend having the same physical key file referenced by each project in the project properties, rather than copying it to each project.

Thus, they are all associated with the same PublicKey constant. And use one entry, for example:

 [assembly: System.Runtime.CompilerServices.InternalsVisibleTo("UnitTests, PublicKey=<your key>")]
+8
source

Source: https://habr.com/ru/post/1415156/

More articles:


All Articles