On Feb 14, 7:43 am, Jonathon Rossi <[email protected]> wrote:
> When the DLLs are merged those types get excluded from being internalized.
>
> I couldn't find the set up in either NMock3's or Moq's repo, but RhinoMocks
> has the ILMerge exclude file checked
> in:https://github.com/ayende/rhino-mocks/blob/master/ilmerge.exclude
>
>
Thanks! I discovered NMock's exclusions file in MAIN/Source/NMock/
ilmerge.exclusions.txt.
The official NMock3 binary does expose those Castle classes as well.
Now my question is, can I avoid that?
I tried placing an InternalsVisibleTo("DynamicProxyGenAssembly2") in
NMock itself (so the internalized Castle classes are accessible by the
proxy), but this doesn't seem to have any effect. I also noticed there
is a DynProxy.snk which is probably used to sign the proxy assembly
(is that even necessary? The proxy isn't reference by strong-named
assemblies, so shouldn't it work not strong-naming the proxy across
all cases?), complicating things.
I had created a nice build of NMock2 with an older version of
Castle.DynamicProxy where nothing of Castle was visible from the
outside, so it had been possible in the past :)
--
You received this message because you are subscribed to the Google Groups
"Castle Project Development List" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en.
