Mocking internal types

728 views
Skip to first unread message

yesthatmcgurk

unread,
Jul 2, 2008, 5:06:54 PM7/2/08
to Moq Discussions
I've got an internal type I want to mock, but I get the error message:

Castle.DynamicProxy.Generators.GeneratorException: Type is not public,
so a proxy cannot be generated. Type: Shaolin.Core.IProviderContainer.

The thing is that I marked my assembly as InternalsVisibleTo the Moq
dll (I have to do this for all my unit test projects, so I know that I
did it right).

What I'm not sure of is if the fact that the moq binaries are merged
with the castle binaries, how does that effect InternalsVisibleTo? Is
there a castle DLL sitting inside the Moq dll that I have to grant
access to my internals to? Or should the castle dynamic proxy
generator have access to whatever the Moq dll has access to?

Nathan Stott

unread,
Jul 2, 2008, 5:25:26 PM7/2/08
to moq...@googlegroups.com
You can't mock internal types. It's a limitation of dynamic proxy.

Daniel Cazzulino

unread,
Jul 2, 2008, 10:51:40 PM7/2/08
to moq...@googlegroups.com
Actually, looks like you can.

See http://forum.castleproject.org/viewtopic.php?t=1975

The fact that DP is embedded in Moq doesn't change the behavior of the
generated assembly, which is the one yours has to be "friend" of

yesthatmcgurk

unread,
Jul 3, 2008, 8:26:55 AM7/3/08
to Moq Discussions
Odd, I did that and it still isn't working. Maybe they changed their
key pair?

On Jul 2, 10:51 pm, "Daniel Cazzulino" <dan...@cazzulino.com> wrote:
> Actually, looks like you can.
>
> Seehttp://forum.castleproject.org/viewtopic.php?t=1975
>
> The fact that DP is embedded in Moq doesn't change the behavior of the
> generated assembly, which is the one yours has to be "friend" of
>
>
>
> On Wed, Jul 2, 2008 at 6:25 PM, Nathan Stott <nrst...@gmail.com> wrote:
>
> > You can't mock internal types.  It's a limitation of dynamic proxy.
>
> > On Wed, Jul 2, 2008 at 5:06 PM, yesthatmcgurk <yesthatmcg...@gmail.com> wrote:
>
> >> I've got an internal type I want to mock, but I get the error message:
>
> >> Castle.DynamicProxy.Generators.GeneratorException: Type is not public,
> >> so a proxy cannot be generated. Type: Shaolin.Core.IProviderContainer.
>
> >> The thing is that I marked my assembly as InternalsVisibleTo the Moq
> >> dll (I have to do this for all my unit test projects, so I know that I
> >> did it right).
>
> >> What I'm not sure of is if the fact that the moq binaries are merged
> >> with the castle binaries, how does that effect InternalsVisibleTo?  Is
> >> there a castle DLL sitting inside the Moq dll that I have to grant
> >> access to my internals to?  Or should the castle dynamic proxy
> >> generator have access to whatever the Moq dll has access to?- Hide quoted text -
>
> - Show quoted text -

ashmind

unread,
Jul 3, 2008, 12:07:10 PM7/3/08
to Moq Discussions
DynamicProxyGenAssembly2 without any key works for me.
http://blog.ashmind.com/index.php/2008/05/09/mocking-internal-interfaces-with-moq/.

yesthatmcgurk

unread,
Jul 3, 2008, 1:15:38 PM7/3/08
to Moq Discussions
This won't work if your assemblies are strong named (mine are). I did
add another internalsvisibleto for DynamicProxyGenAssembly2 with the
same public key as the one above but it still doesn't work. I'm going
to do a little spelunking with reflector to see if I find anything
interesting...

On Jul 3, 12:07 pm, ashmind <ashm...@gmail.com> wrote:
> DynamicProxyGenAssembly2 without any key works for me.http://blog.ashmind.com/index.php/2008/05/09/mocking-internal-interfa....
> > > - Show quoted text -- Hide quoted text -

yesthatmcgurk

unread,
Jul 3, 2008, 2:13:58 PM7/3/08
to Moq Discussions
Well, I verified the proxy assembly is strong named, re-extracted the
public key, rewrote the internals attribute, and now it works fine.
The correct internals attribute is:


[assembly:
System.Runtime.CompilerServices.InternalsVisibleTo("DynamicProxyGenAssembly2,
PublicKey=0024000004800000940000000602000000240000525341310004000001000100c547cac37abd99c8db225ef2f6c8a3602f3b3606cc9891605d02baa56104f4cfc0734aa39b93bf7852f7d9266654753cc297e7d2edfe0bac1cdcf9f717241550e0a7b191195b7667bb4f64bcb8e2121380fd1d9d46ad2d92d2d15605093924cceaf74c4861eff62abf69b9291ed0a340e113be11e6a7d3113e92484cf7045cc7")]

(hope Google doesn't screw that up too bad). I wrapped it in a #if
DEBUG ... #endif so my types aren't exposed in the production
environs. Altho, I am waiting for the day somebody pirates/cracks one
of my apps. That would be AWESOME.

yesthatmcgurk

unread,
Jul 3, 2008, 4:09:58 PM7/3/08
to Moq Discussions
Google screwed it up bad. Copy the whole thing into notepad, remove
every - and put it all on one line.

On Jul 3, 2:13 pm, yesthatmcgurk <yesthatmcg...@gmail.com> wrote:
> Well, I verified the proxy assembly is strong named, re-extracted the
> public key, rewrote the internals attribute, and now it works fine.
> The correct internals attribute is:
>
> [assembly:
> System.Runtime.CompilerServices.InternalsVisibleTo("DynamicProxyGenAssembly­2,
> PublicKey=0024000004800000940000000602000000240000525341310004000001000100c­547cac37abd99c8db225ef2f6c8a3602f3b3606cc9891605d02baa56104f4cfc0734aa39b93­bf7852f7d9266654753cc297e7d2edfe0bac1cdcf9f717241550e0a7b191195b7667bb4f64b­cb8e2121380fd1d9d46ad2d92d2d15605093924cceaf74c4861eff62abf69b9291ed0a340e1­13be11e6a7d3113e92484cf7045cc7")]
Reply all
Reply to author
Forward
0 new messages