I ran into an interesting situation the other day while using the InternalsVisibleToAttribute. Our team is developing three libraries as part of our current project, and all three of them are signed with the same key. Assembly A makes its internals visible to Assembly B and C. Assembly A and B build successfully, but Assembly C fails with the error:
Friend access was granted to ‘AssemblyC, PublicKey=0024000004800000…’, but the output assembly is named ‘AssemblyC, Version=126.96.36.199, Culture=neutral, PublicKeyToken=null’. Try adding a reference to ‘AssemblyC, PublicKey=0024000004800000…’ or changing the output assembly name to match.
We obviously can’t add a reference to Assembly C in Assembly A, as that would cause a circular dependency. The only clue we could get out of that error message is the PublicKeyToken=null bit. Why would the PublicKeyToken be null if the assembly is signed? I wanted to confirm that the assembly was signed with Reflector or sn.exe, but there was no dll to check because the build failed. After commenting out all of the code that accessed the internal parts of Assembly A, we got Assembly C to build and confirmed that it was indeed signed. From the output window, we saw that the “WorkflowCompilation” task was executing and failing, and that the “CoreCompile” wasn’t even running. It seems that the compilation fails because Assembly C is not yet signed when the compiler attempts to verify the InternalsVisibleTo attribute on Assembly A. We managed to get the project to build by adding the AssemblyKeyFile attribute to it:
This produces the warnings “Use command line option ‘/keyfile’ or appropriate project settings instead of ‘AssemblyKeyFile'” and “Option ‘keyfile’ overrides attribute ‘System.Reflection.AssemblyKeyFileAttribute’ given in a source file or added module” that we have to ignore. I’ve found this problem to happen to any workflow assemblies that attempt to access the internals of another assembly. I’ve submitted a bug report about it here.