1

I'm having an issue getting the public keys for some of the .net 4.0 beta 2 assemblies so I can make my internals visible to them (gross).

Normally, I'd just pop into SN.EXE and poof I'd have them.

But instead of getting what I'd normally expect I'm getting a bogus public key, and I'm not sure exactly why.

I'm using the 64bit version of SN

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64>sn.exe

I'm using it against the 64bit version of the dll I'm targeting:

C:\Windows\Microsoft.NET\Framework64\v4.0.21006\system.xaml.dll

and I'm getting this as my output:

Public key is 00000000000000000400000000000000

Public key token is b77a5c561934e089

The token is correct, but the public key is BS. What's going on here??

1 Answers1

1

That's the ECMA public key. See http://blogs.msdn.com/shawnfa/archive/2004/06/09/152097.aspx

Mattias S
  • 4,748
  • 2
  • 17
  • 18
  • Nice. +1 for the info. Any idea why I can't get the internals attribute working with this public key? –  Nov 24 '09 at 14:06
  • What happens when you use it? And why do you use it? Only framework assemblies are signed with this key, and I don't see why they would need access to internals in your code. – Mattias S Nov 24 '09 at 15:32
  • It doesn't work is what happens. The reason why is a bit complex; I'm trying to keep some components out of the toolbox in WF 4.0.... essentially, its for deserialization of internal types, which the new xaml object deserializer chokes on. Figured if I selectively made my internal types visible to some framework assemblies it might solve that issue... –  Nov 24 '09 at 17:11