3

I have a strongly named c# assembly: Strong.Named.Assembly.dll. It has the attribute InternalsVisibleTo with its public key, for another assembly: [assembly: InternalsVisibleTo("Another.Assembly, PublicKey=xxx")]. The Anoter.Assembly has not been signed. And so I was not able to reference classes in the Strong.Named.Assembly until I singed the Another.Assembly, too.

Why isn't it possible to show to internals of a strongly named assembly to a not signed one?

Martin Rosenau
  • 17,897
  • 3
  • 19
  • 38
scher
  • 1,813
  • 2
  • 18
  • 39
  • I changed the tag "assembly" to ".net-assembly" because the tag "assembly" is about assembly language... – Martin Rosenau Oct 23 '17 at 06:26
  • 1
    Wouldn't make a lot of sense to put this kind of restriction on an assembly when anyone could just use one of the "allowed" AssemblyNames to gain access. The PublicKey makes sure it really is the one you wanted. – Manfred Radlwimmer Oct 23 '17 at 06:29
  • And why do you need that? – Evk Oct 23 '17 at 07:20
  • I don't need it. I run into it, because by default projects does not have a strong name. I just wanted to know the reason of this behaviour. – scher Oct 23 '17 at 07:21
  • Well only developers know this, but I suppose for security reasons. Signed assemblies are treated as more "secure" and if any unsigned assembly can use its internal types (by using correct name) - kind of violates that. For the same reason you cannot reference unsigned assemblies from signed ones. – Evk Oct 23 '17 at 07:34
  • @Evk: This might be the reason. Thanks – scher Oct 23 '17 at 07:53

1 Answers1

3

Take a look at the MSDN InternalsVisibleToAttribute Class. The documentation states clear that "Both the current assembly and the friend assembly must be unsigned, or both assemblies must be signed with a strong name."

I think the reason for that is obvious. It guarantees that the assembly you grant internal access to cannot attack your implementation if it changes in future.

MiGro
  • 471
  • 1
  • 4
  • 17