Andrey, have you tried [assembly: InternalsVisibleTo(RhinoMocks.StrongName)]?

I’m pretty smart and I spend a fair amount of time thinking about these issues upfront so that they are “solved by default.” But I will miss stuff or I will postpone it due to conflicting priorities.

So I count on the community of other smart people like yourself to point out deficiencies that affect them so that they can be directly addressed.

Also keep in mind that I only found this post accidentally. So you’re lucky I even noticed it at all. The issue tracker and mailing lists are much better ways to ensure that your feedback gets noticed and taken into consideration.

As for Gallio, I’ll enjoy working with it when it’s out, but it is not here yet. So, since I wanted to extend a stable version, I haven’t looked deep into Gallio.

This is something I have *thought* very carefully about. Trust me. I don’t doubt we could do even better. Let me know if you have any ideas. (MbUnit v2 is a different story.)

As for internal test fixtures, this is something we have considered and can very easily change. It’s not entirely clear its a good idea. For example, we might encounter problems in partial trust execution environments.

However, you do make a good case regarding the interaction with [InternalsVisibleTo] and the implied constraints on the visibility of any derived types. Previous requests for this feature have largely been from people wanting to mix test fixtures with production code.

In any case I’ll go ahead and enable internal fixtures in the next update. Not really worth fussing over.

In the future, if there’s anything else you want a tool to do, please just ask for it. It might already be there or it might be something that has just yet to be done pending sufficient demand.