Static classes

[Simon Cropp]

Does RhinoMocks support static classes or static methods?

[Ayende Rahien]

No, you can either use as adapter class or try Type Mock

[Simon Cropp]

Unfortunately the free version of TypeMock does not support code coverage.
And at $279.00 US for the pro version is a lot to pay just to get code coverage.

Do you think it would be possible to implement support for static
classes in RhinoMock using the CLR Debugging Services APIs? There is a
sample here (http://www.microsoft.com/downloads/details.aspx?familyid=38449a42-6b7a-4e28-80ce-c55645ab1310&displaylang=en)
In theory with the features of a debugger (breakpoints, changing
executing line numbers etc) is should be possible to intercept calls
to static classes.

Just curious if anyone has looked into this.

[Ayende Rahien]

In theory, yes, but that is going to be a lot of work.
If you can build a proof of concept for that, I would be happy to take that further.

[Jeff Brown]

I went hunting around for an AOP system for .Net based on the debugger APIs and/or profiler APIs.  You know what?  There just aren't any!  There are research papers and prototypes but no actual code.

 

I'm actually a little disappointed.  But then I haven't ponied up the time to help implement one yet.  Frankly, I don't think I'd want to bother until the CLR provided something more suitable for runtime weaving without the overhead and inconveniences of using these APIs.

 

Pity we can't just replace methods at runtime as with dynamic languages.  Self would automatically deoptimize JITted method when a method they dependend on was changed (because its address may have changed or it may have been inlined).  Pity the CLR can't do that.  I wonder what the runtime impact of maintaining a linked list of dependent method tokens would be plus synchronization issues during deoptimization...

 

Anyways here's an interesting paper for AOP based on the debugger API: http://www.iks.inf.ethz.ch/publications/files/daopnet.pdf

 

Jeff.

---

From: Rhino...@googlegroups.com [mailto:Rhino...@googlegroups.com] On Behalf Of Ayende Rahien
Sent: Tuesday, August 14, 2007 10:59 PM
To: Rhino...@googlegroups.com
Subject: Re: Static classes

[Ayende Rahien]

You can check my post on AOP in .NET, there are no runtime support for it.
What you can do is use the unmanaged profiling API to do it, but I have yet to see code that I would use.

On 8/15/07, Jeff Brown <Je...@ingenio.com> wrote:

I went hunting around for an AOP system for .Net based on the debugger APIs and/or profiler APIs.  You know what?  There just aren't any!  There are research papers and prototypes but no actual code.

 

I'm actually a little disappointed.  But then I haven't ponied up the time to help implement one yet.  Frankly, I don't think I'd want to bother until the CLR provided something more suitable for runtime weaving without the overhead and inconveniences of using these APIs.

 

Pity we can't just replace methods at runtime as with dynamic languages.  Self would automatically deoptimize JITted method when a method they dependend on was changed (because its address may have changed or it may have been inlined).  Pity the CLR can't do that.  I wonder what the runtime impact of maintaining a linked list of dependent method tokens would be plus synchronization issues during deoptimization...

 

Anyways here's an interesting paper for AOP based on the debugger API: http://www.iks.inf.ethz.ch/publications/files/daopnet.pdf

 

Jeff.

---

From: Rhino...@googlegroups.com [mailto:Rhino...@googlegroups.com] On Behalf Of Ayende Rahien
Sent: Tuesday, August 14, 2007 10:59 PM
To: Rhino...@googlegroups.com
Subject: Re: Static classes

In theory, yes, but that is going to be a lot of work.
If you can build a proof of concept for that, I would be happy to take that further.

On 8/15/07, Simon Cropp <simon...@gmail.com> wrote:

Unfortunately the free version of TypeMock does not support code coverage.
And at $279.00 US for the pro version is a lot to pay just to get code coverage.

Do you think it would be possible to implement support for static
classes in RhinoMock using the CLR Debugging Services APIs? There is a

sample here ( http://www.microsoft.com/downloads/details.aspx?familyid=38449a42-6b7a-4e28-80ce-c55645ab1310&displaylang=en )

[Fabian Schmied]

> I went hunting around for an AOP system for .Net based on the debugger APIs
> and/or profiler APIs. You know what? There just aren't any! There are
> research papers and prototypes but no actual code.

There's a simple reason for that: people developing AOP tools usually
want their tools to be usable to create real software. If you use the
profiling or debugging APIs, you can forget that - it's way too slow
and it disables the use of "real" debuggers/profilers. That's why AOP
tool developers usually go for either compilers, IL rewriters, or
dynamic proxies.

Of course, sometimes it would be handy to have an AOP tool based on
the profiling API for development (e.g. for unit testing or special
debugging). But the profiling API is very hard to use, it's incredibly
easy to do something the wrong way (much easier than with
System.Reflection.Emit...), and it's quite hard to debug. I know
because I wrote a prototype... (That was back in 1.1, and it doesn't
work with 2.0 any longer.) It's certainly easier to refactor you code
so that it becomes mockable with RhinoMocks.

Fabian

[Ayende Rahien]

>  (much easier than with System.Reflection.Emit...),

That is saying much, thanks for the warning.

[Jeff Brown]

Yup. I wouldn't use something based on debugger or profiler APIs in
production. I'd rather do compile-time or load-time weaving of
join-points and then apply dynamic aspects on top of that.

Jeff.

-----Original Message-----
From: Rhino...@googlegroups.com [mailto:Rhino...@googlegroups.com]
On Behalf Of Fabian Schmied
Sent: Wednesday, August 15, 2007 2:13 AM
To: Rhino...@googlegroups.com
Subject: Re: Static classes

[Simon Cropp]

Agreed.
But we are talking about using if for unit testing not production use.
Pity the managed debugger samples are all so complex.

[Jeff Brown]

Well...
I still don't think I would want to hook into the debugger or profiler APIs just the same because that'll interfere with real debuggers and profilers - just the kind of tools most often used wirh tests.

However, if it were possible to load assemblies into the dynamic assembly context we could use MethodRental to perform on-the-fly substitutions as needed. MethodRental isn't the only option of course. Given control over how assemblies are loaded, we could instrument them in most any way we like. It would need help from the test framework to hijack assembly loading. Hrm...

(This is interesting to consider given I'm designing the next version of MbUnit.)

Jeff.

________________________________

[Ayende Rahien]

MethodRental ??

The idea of an assembly re-write is quite interesting to me, and entirely possible with Cecil.
But, the problem is that you want to mock a framework class that is sealed, or a static method, and you cannot do that, at least as far as I know.
At the very least, you would need to do runtime re-write of the entire framework, and I am not sure that this is possible (mscorlib.dll is a big problem there :-) ).
Do you have any idea how this can be used?

> profiling API for development ( e.g. for unit testing or special

[Simon Cropp]

Don't know.
I have always been curious about how TypeMock does it?

[Ayende Rahien]

Profiler API

[Ayende Rahien]

From my discussion with Eli, it is about 3-5% cost for just the interception, which is very good, and would cause me to put it in production without hesitations.
They are yet to come up with just interception framework, though.

[Jeff Brown]

Except then you can't run NCover on your tests anymore.  So either we need composable re-entrant debugger and profiler APIs or the CLR team just needs to provide a managed interception API.  Personally I'd prefer the latter.

 

Jeff.

---

From: Rhino...@googlegroups.com [mailto:Rhino...@googlegroups.com] On Behalf Of Ayende Rahien
Sent: Wednesday, August 15, 2007 11:05 PM

[Ayende Rahien]

So do I.
Another option is runtime weaving, but that stops at the framework level.
Do you know of a way to replace assembly load at runtime?