4

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

Just for interest, how would it be practical to use signed assemblies and InternalsVisibleTo? In order to use InternalsVisibleTo for specifying a signed friend assembly, I need to specify its public key. I have it only after compiling the friend assembly which has a dependency on the assembly under test (dynamic assembly loading and reflexion left aside, what would bloat-up coding and readability). This sound like a chicken-egg problem requiring a bootstrap of the assembly to be tested. I can imagine some tricks with MSBuild and scripting to automate this. Is there a more practical way of doing this?

In case it remains so tedious I will stick to my first idea of dropping Unit Testing for the release builds (which is somewhat unsatisfying as subtle timing issues could be left untested...)

jdehaan
  • 19,700
  • 6
  • 57
  • 97
  • Unless you generate a new key file during your build process (highly unlikely), the public key will be a constant value... – Damien_The_Unbeliever May 30 '12 at 14:47
  • 2
    Why do you think this is a security issue? Strong name aren't about security. It's trivial for a user to disable strong name validation and use your assembly in ways you didn't intent. – Daniel May 30 '12 at 15:43
  • So Daniel I do not to worry about this at all if I understand you well and can leave the assemblies unsigned. This would just ensure a user that the origin of the software is safe if the strong name can be trusted. If the assemblies are deployed in a "safe" environment like inside our company then I do not need to bother with signing. Is this a correct statement? – jdehaan May 30 '12 at 19:37

1 Answers1

10

Use the same key to sign all the projects in the solution, don't generate a different one for each project and on each build. I'd recommend having the same physical key file referenced by each project in the project properties, instead of copying it into each project.

That way, all of them are associated with the same PublicKey constant. And use a single entry, such as:

[assembly: System.Runtime.CompilerServices.InternalsVisibleTo("UnitTests, PublicKey=<your key>")]
Pablo Romeo
  • 11,298
  • 2
  • 30
  • 58
  • Gosh, I think I didn't get this point right in mind. Life can be so easy... I thought the key was dependent on the assembly content. I need to get into this soon. Thanks for this precision. I am a noob in signing. – jdehaan May 30 '12 at 19:32