Getting InternalsVisibleTo to work when the build process signs the assembly with strong names?

Question

In our store, we use Cruise Control and MSBuild to automate product assembly as part of continuous integration.

Part of the assembly is to sign the assemblies so that they have strong names.

In our project files, when we develop locally, it does not indicate a signature, as this is overridden by the MSBuild script.

This is all good and good, until I decided that I would like to introduce unit tests that require me to use the InternalsVisibleTo attribute. I also started using a good open source library that has unit tests that also use this technique.

This means that on my machine, I can update AssemblyInfo.cs to use the following statement:

 [assembly: InternalsVisibleTo("MyProject.Tests.UnitTests")] 

and everything's good.

However, checking this when the assembly breaks, as the assembly machine signs the assemblies, this line should be updated to look like this:

 [assembly: InternalsVisibleTo("MyProject.Tests.UnitTests, PublicKey="magic key here..)"] 

I have half the mind not to sign meetings and call it day. However, “signing assemblies is the best practice” (repeat this mantra 3 times), and if we get any benefit from it, I don’t want to delete it.

We do not install in the GAC, we are not particularly worried about fakes, there is no need to worry about third parties who use our libraries, we update all our files immediately when updating the application. The most recognizable advantage is that someone in support cannot copy some random version of the assembly to a temporary folder and something seems to work for a while.

I do not want to open a bank of works related to changing about 100 project files manually to enable a signature. I also don’t want to hack things by marking things that should be internal as public, I don’t want to rewrite redirects, and I don’t want to remove unit tests.

I would like the whole simple lack of strong names with all the advantages of having strong names (if any), and I don't want to create a lot of extra work for this. Is it too much to ask?

This post describes the problem and solution, but I do not have much from the MSBuild script to take advantage of this:

http://social.msdn.microsoft.com/forums/en-US/msbuild/thread/02df643c-956a-48bd-ac01-4a1016d91032/

What is the correct solution to this problem?

Any materials and discussion points are welcome.

Answer 1

You can correct key information in source files before compilation.

The following example uses FileUpdate from the MSBuild Community Tasks and a (very rude) regular expression to fix key information in C # AssemblyInfo. cs.

 <ItemGroup> <AssemblyInfoFiles Include="$(MSBuildProjectDirectory)**/AssemblyInfo.cs"/> </ItemGroup> <FileUpdate Files="@(AssemblyInfoFiles)" Regex='(\[assembly:\s*InternalsVisibleTo\(\"[\w.]*\")(\)\])' ReplacementText='$1, PublicKey="$(StrongNamingPublicKey)"$2' /> 

However, I think that changing projects to always a strong sign will be a clean solution to eliminate another difference between the development and deployment environments and can be easily scripted.

Answer 2

Use the same construct you use to disable signing the developer assembly to define a compiler symbol, for example. DO_NOT_SIGN, then in your AssemblyInfo.cs use this:

 #if DO_NOT_SIGN [assembly: InternalsVisibleTo("MyProject.Tests.UnitTests")] #else [assembly: InternalsVisibleTo("MyProject.Tests.UnitTests, PublicKey="magic key here..)"] #endif 

In my personal opinion, this is more elegant than modifying the source code from a build script.