chevron-thin-right chevron-thin-left brand cancel-circle search youtube-icon google-plus-icon linkedin-icon facebook-icon twitter-icon toolbox download check linkedin phone twitter-old google-plus facebook profile-male chat calendar profile-male
0 votes
Well, my previous observation led me to a question about remoting in general: if an object is created remotely, is there any chance to simulate its behavior using mock objects, ether natural or reflective? I can not get access to System.Runtime.Remoting.__TransparentProxy type, because it's protected, so I can't even write "typeof" in my program. And this is the type that CLR uses to instantiate remote objects.

asked by vagif (19.4k points)

2 Answers

0 votes
See the answer to the previous post:

You are correct, the __TransparentProxy is in mscorlib, and it is not possible to mock.
We should actually support this scenario. I will add it as a feature to a future version of TypeMock.

Thanks for pointing out this scenario
answered by scott (32k points)
0 votes

First of all, thanks for your quick replies. You are on the other side of the globe, aren't you? Or maybe I am on the other :-) Anyway, we are probably separated by many timezones and it looks like you guys are always available.

Back to the topic. Since mocks are especially useful in enterprise scenario where there is a need to simulate responses from remote components, it is very likely that access to such components are gained via remoting, DCOM, multiple AppDomains etc. Right now I've found a workaround by writing a proxy object for my tests, but it is very time consuming (and kills much of mock transparency). So it will be great if you can address this.
answered by vagif (19.4k points)