Rhino Mocks & Castle Dynamic Proxy

[Ayende Rahien]

I am in merging hell, and I don't like it.

The problem, advance users of Rhino Mocks (aka, yours truly, among others), are using Rhino Mocks as well as Castle Dynamic Proxy.
Rhino Mocks is merged with DP to make deployment easier.
So far so good, but this cause conflicts when we are using both of them together.

I tried to make Castle DP entirely internal, but that doesn't work. Currently, I am not sure what to do.
I tried playing with this a bit: http://www.ayende.com/Blog/archive/2007/05/30/This-Is-Not-Open-SourceTM.aspx
But it is non trivial, and will play hell with debugging.

Suggetions?

[Ken Egozi]

stop merging. if someone want his project deployed as a single dll, one can merge himself.

why do you have deployment issues with a mocks framework? do you deploy test projects?

--
Ken Egozi.
http://www.kenegozi.com/blog
http://www.musicglue.com
http://www.castleproject.org
http://www.mamaherb.com
http://www.gotfriends.co.il

[Ayende Rahien]

A) I did deploy Rhino Mocks for production a few times. You will be surprised.
B) It means having only a single DLL instead of three.

[Ernst Naezer]

I don't mind having multiple dll's, and never merge. It also makes it
easier for me to track dependencies between project and have a quick
look of what versions there are in my project. I also makes my build
scripts a simple copy action :)

[Ayende Rahien]

You are not the target audience for this.

It means that using Rhino Mocks is as simple as referencing a single DLL.

I consider this important

[Markus Zywitza]

Copy the RM dll before merging into Rhino.Mocks.Pure.dll and tell
users that issues with Castle to use Rhino.Mocks.Pure instead
Rhino.Mocks. They'll have references to Castle.Core and
Castle.DynamicProxy nonetheless.

[Ayende Rahien]

That means that we will have two versions.
I don't like it, but I think this is the way to go

[Omer Mor]

1) I think like Oren that merging is a must.
2) I also encountered problems with mocking in a castle-consuming
test.
3) I want to believe this is solvable without resolving to delivering
2 dlls.

As far as I know, the only reason for not making castle fully
internal, is the exposure of the IInvocation interface through the new
mock .Do() overload. As think this can be remedied by not using the
castle IInvocation interface here, and instead use a new interface,
that will be converted to the internal IInvocation inside the mocking
framework.

I am willing to try and help solving this.

- Omer Mor.

On Jul 10, 4:17 pm, "Ayende Rahien" <aye...@ayende.com> wrote:
> That means that we will have two versions.
> I don't like it, but I think this is the way to go
>

> On Thu, Jul 10, 2008 at 4:14 PM, Markus Zywitza <markus.zywi...@gmail.com>

> wrote:
>
>
>
> > Copy the RM dll before merging into Rhino.Mocks.Pure.dll and tell
> > users that issues with Castle to use Rhino.Mocks.Pure instead
> > Rhino.Mocks. They'll have references to Castle.Core and
> > Castle.DynamicProxy nonetheless.
>
> > On 7/10/08, Ayende Rahien <aye...@ayende.com> wrote:
> > > You are not the target audience for this.
> > > It means that using Rhino Mocks is as simple as referencing a single DLL.
> > > I consider this important
>

> > > On Thu, Jul 10, 2008 at 2:11 PM, Ernst Naezer <ernstnae...@gmail.com>

> > wrote:
>
> > > > I don't mind having multiple dll's, and never merge. It also makes it
> > > > easier for me to track dependencies between project and have a quick
> > > > look of what versions there are in my project. I also makes my build
> > > > scripts a simple copy action :)
>
> > > > On Thu, Jul 10, 2008 at 11:30 AM, Ayende Rahien <aye...@ayende.com>
> > wrote:
> > > > > A) I did deploy Rhino Mocks for production a few times. You will be
> > > > > surprised.
> > > > > B) It means having only a single DLL instead of three.
>

> > > > > On Thu, Jul 10, 2008 at 12:15 PM, Ken Egozi <egoz...@gmail.com>

> > wrote:
>
> > > > >> stop merging. if someone want his project deployed as a single dll,
> > one
> > > > >> can merge himself.
>
> > > > >> why do you have deployment issues with a mocks framework? do you
> > deploy
> > > > >> test projects?
>
> > > > >> On Thu, Jul 10, 2008 at 12:05 PM, Ayende Rahien <aye...@ayende.com>
> > > wrote:
>
> > > > >>> I am in merging hell, and I don't like it.
>
> > > > >>> The problem, advance users of Rhino Mocks (aka, yours truly, among
> > > > >>> others), are using Rhino Mocks as well as Castle Dynamic Proxy.
> > > > >>> Rhino Mocks is merged with DP to make deployment easier.
> > > > >>> So far so good, but this cause conflicts when we are using both of
> > > them
> > > > >>> together.
>
> > > > >>> I tried to make Castle DP entirely internal, but that doesn't work.
> > > > >>> Currently, I am not sure what to do.
> > > > >>> I tried playing with this a bit:
>

> >http://www.ayende.com/Blog/archive/2007/05/30/This-Is-Not-Open-Source...

[Ayende Rahien]

We are exposing this API in several place. Extensions to Rhino Mocks (used once in three years, I don't care about that) and when we inherit from them in the proxies themselves.

[Omer Mor]

But it was exposed there in previous versions too, but the merge
operation successfully internalized the castle assemblies.
So what was changed in the version that broke the internalization step
of ILMerge ?
- Omer Mor.

On Jul 11, 12:40 am, "Ayende Rahien" <aye...@ayende.com> wrote:
> We are exposing this API in several place. Extensions to Rhino Mocks (used
> once in three years, I don't care about that) and when we inherit from them
> in the proxies themselves.
>

[Ayende Rahien]

Not a single clue.

[Omer Mor]

With the latest revision from the trunk, I managed to get a working
(and merged) Rhino.Mocks.dll that had everything internalized. I only
needed to change your ilmerge.exclude file to it's older state which
has the following single line:

Castle.Core.Interceptor.IProxyTargetAccessor

I used the nant script to build everything, but the tests failed. I'm
not sure if they failed for the right reasons - someone who knows them
better should check it. I tried to use this dll in some scenarios and
it works great, even side-by-side with castle assemblies.

-- Omer.

On Jul 11, 9:30 am, "Ayende Rahien" <aye...@ayende.com> wrote:
> Not a single clue.
>

[Ryan Scott]

I opened a thread on this a few weeks ago. In the last few posts in
the thread, I describe a method for getting Rhino mocks to work along
side castle with the castle portions public.

http://groups.google.com/group/rhino-tools-dev/browse_thread/thread/f3f55052e26eece4/cc9fcda934eaec95?lnk=gst&q=rscot231#cc9fcda934eaec95

[Ayende Rahien]

I run into issues doing that, specifically, the tests wouldn't work.
Were you able to run all the tests using this approach?

[Omer Mor]

Oren, as I said: the only issue I had was with the tests, but when i
tried it dll it worked for me.
Maybe there's only a small issue with the tests, but I don't know
those good enough to check.

Ryan: I am already using the assembly alias method to solve this, but
this is burdensome, and ReSharper hates me for doing that... I'd still
rather see this fixed.

Omer.

On Aug 2, 10:32 pm, "Ayende Rahien" <aye...@ayende.com> wrote:
> I run into issues doing that, specifically, the tests wouldn't work.
> Were you able to run all the tests using this approach?
>

[Ayende Rahien]

When I tried that, other assemblies could not use this to mock anything.