InternalsVisibleTo(RhinoMocks.StrongName) no longer works for V3.2, V3.3?

[wel...@gmail.com]

Oren,

First, and most importantly, thank you for RhinoMocks! It is a great
help to us. 8)

We have run into an odd issue with V3.2 and v3.3. Specifially, with
v3.1 we were able to give Rhino.Mocks.dll access to our internal
interfaces by adding the following line to the AssemblyInfo.cs of our
test code:

[assembly: InternalsVisibleTo(RhinoMocks.StrongName)]

We recently tried to upgrade to V3.3 and had to make the following
peculiar change to get our tests working again:

//To use RhinoMocks V3.2 or V3.3, use the following:
[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")]
//But be careful, because this doesn't have public key

This is a bit worrisome to us, because this would presumably allow for
Trojan Horse attacks via a rogue Rhino.Mocks.dll masquerading as the
real Rhino.Mocks.dll (would that be a TrojanRhino?).

Anyhow, we've reverted to V3.1 and are sadly watch you make good stuff
happen but not being able to use it.

What are your thoughts on this situation?

Thanks,
--Karl Lew

[Ayende Rahien]

It looks like you are using a version that is not signed, which doesn't really make much sense at all.

[karl lew]

Hmm. I'll look into it again. You're right. That is MOST odd.

 

Thanks,

--Karl

 

[Drew Noakes]

We're encountering this too. Has there been any progress on this?

//[assembly: InternalsVisibleTo(RhinoMocks.StrongName)] <-- doesn't
work any more
[assembly: InternalsVisibleTo(RhinoMocks.NormalName)] // <-- this
works instead though

----

'DynamicProxyGenAssembly2, Version=0.0.0.0, Culture=neutral,
PublicKeyToken=null' is attempting to implement an inaccessible
interface.
at System.Reflection.Emit.TypeBuilder.TermCreateClass(Int32 handle,
Module module)

----

We have:

Rhino.Mocks
Version: 3.3.0.906
Strong Name: True
Runtime Version: v2.0.50727

[Ayende Rahien]

Interesting, I can't reproduce on the trunk.

Can you try 3.4, or wait for 3.5?

[Rasmus Hansen]

Hi Ayende.

We have upgraded to 3.4 (from 2.8.8) and are experiencing the same
problem. It seems that DynamicProxyGenAssembly2 is not strong named in
3.4 - and thus our assembly cannot be strong named if we want to use
InternalsVisibleTo

Kind regards
Rasmus Hansen


On May 5, 2:19 am, "Ayende Rahien" <aye...@ayende.com> wrote:
> Interesting, I can't reproduce on the trunk.Can you try 3.4, or wait for
> 3.5?

[Ayende Rahien]

This will be fixed in 3.5, can you check this with the beta?