Comments on: InternalsVisibleTo and strong names

by: Brian Johnston

Fri, 31 Oct 2008 02:38:47 +0000

I can confirm response #14 - in VS2008, had to use PublicKey and full hex public key extracted as shown above. What a PIA. Visual Studio team shouldn’t make it so hard to do basic security - no wonder so many people don’t sign their files when you have to go through all this!

by: Pspallone

Tue, 08 Apr 2008 23:12:36 +0000

I could not get mine to compile and see the internals until I found another post which said to use PublicKey (instead of PublicKeyToken) and use the actual hex public key (extracted from my unitTest binary using sn -Tp myunitTest.dll

by: Gareth

Tue, 25 Mar 2008 15:34:36 +0000

Firstly thanks for the article, im new to c# and .net (came from php5), and this has helped me get InternalsVisibleTo working.
I do have one slight ‘odity’ in VS2008 however. I have a solution with 2 projects, one is the library code the other a unit test project for the library. When I build the library code all works fine but I don’t get the internal class appearing in the intellisense when using the unit test code. It all compiles fine however - anybody else experiencing this?

by: Michael

Tue, 18 Mar 2008 21:10:07 +0000

"The latest version of the Enterprise Library comes strong named.". I found the lastest version of the Library doesn’t includes strong name

latest library

Is this link correct?

Thank you!

by: Jeremy

Tue, 04 Mar 2008 23:29:25 +0000

Thanks for the info. Very helpful.

new -
The latest version of the Enterprise Library comes strong named. Otherwise, you just have to download the source, go into each project and sign each. Its a PITA, but once you’re done, you have a nice set of signed Enterprise Library dlls.

by: nev

Tue, 04 Mar 2008 10:25:49 +0000

Im working with the Data Block of the Enterprise Library.
Both PublicKey and PublicKeyToken didnt work for me. There seems to be an endless nesting of referenced assemblies that I have to add this attribute to. What is the workaround if any?

by: Michael Flanakin

Thu, 17 Jan 2008 14:07:47 +0000

Just wanted to confirm Andrew’s comment — VS 2008 requires PublicKey; PublicKeyToken does not work.

by: Andrew

Tue, 08 Jan 2008 03:52:03 +0000

Thank you very much!

Specifying [InternalsVisibleTo("MyDll, PublicKey=…")] worked beautifully.

Visual Studio 2008 just simply refused to accepted [InternalsVisibleTo("MyDll, PublicKeyToken=…")]

Thanks again!

by: Justin Scott

Mon, 03 Dec 2007 19:08:09 +0000

Scratch that; I am not able to get PublicKeyToken to work as desired in Orcas.

However, PublicKey still works A-OK.

Use
sn -Tp assembly.dll

which will return:
PublicKey=00240000048…9
PublicKeyToken=123456789abcdef0

Then in code:
[assembly: InternalsVisibleTo("UnitTests, PublicKey=00240000048…9")]

by: Justin Scott

Mon, 03 Dec 2007 18:44:00 +0000

Command is slightly wrong:

Try this:
[assembly: InternalsVisibleTo("UnitTests, PublicKeyToken=<123456789abcdef0>")]

by: Oliver Sturm

Mon, 13 Mar 2006 15:44:57 +0000

Hey Neil -
Certainly an interesting hint, but do you find this more useful? I tried it with my own key and while the token has 16 chars (8 bytes), the complete key string is more than 320 chars long. If I have the choice, I’ll still go with the token

by: Neil Mosafi

Mon, 13 Mar 2006 15:38:31 +0000

The InternalsVisibleTo attribute now uses the public key of the assembly, rather than the public key token. This can be extracted by running:

sn -tp mykey.pub

and using PublicKey= rather than PublicKeyToken=

by: Andrew Davey

Wed, 23 Nov 2005 04:36:33 +0000

Hi, I have come across your same error but with the difference being none of my assemblies were strongly signed.

At first I thought that the documentation included was incorrect and that the final release would only allow you to use the InternalsVisibleTo attribute on strongly signed assemblies. I was in the middle of writing something to MS when I tried to compile their example and was surprised when it worked.

So after much headscractching I discovered that if I removed the following three attributes from my ported AssemblyInfo.cs file:

[assembly: AssemblyDelaySign(false)] [assembly: AssemblyKeyFile("")] [assembly: AssemblyKeyName("")]

Then my error went away. It seems that if the compiler detects the presense of these attributes, for the purposes of the InternalsVisibleTo, it seems to think that the assembly is strongly signed.

by: Oliver Sturm

Thu, 20 Oct 2005 08:49:16 +0000

It does sound correct. What is the error you’re getting? The same message I showed above?

I just double-checked and I find there has to be something funny going on on your end. The thing is this: the compiler checks only for the valid syntax of the string passed to the InternalsVisibleTo attribute. For example, you can even use the string shown above, with the nonsense public key token in it, to make the compiler happy. So if you’re still getting errors, there must be another reason… are you sure you’re not seeing old messages? VS is sometimes great at this… To be sure, the best way is to switch to the Output tab after a compiler run (not the Error list tab!) and check the output carefully - maybe there’s some other problem and VS is showing you the old error.

by: Brad Thompson

Wed, 19 Oct 2005 23:31:42 +0000

Unfortunately, this doesn’t work for me. My method was to edit the unittest code to comment out all references to the main dll. Then compile it with a strong key that I created with sn.exe. I then used sn.exe to get the public key. I included this in the main dll assembly exactly as above, but when I compile I still get the same error. I even GACed the unittest.dll file. Is there anything wrong with my approach?