Rhino Mocks 3.4 Released
Well, it is about that time again, I got enough changes to make a release worthwhile. It has been almost five months, and we got a whole bunch of stuff going on, including a lot of stuff from contributors. (Take that, one man project :-) ).
As usual, you can get it here and the source is available here.
It is interesting to note that a lot of people have stuck with Rhino Mocks 3.1, I guess that there is really no need to upgrade, if you get what you want...
Features, more features, glorious features!
- Added CreateMockWithRemoting and DynamicMockWithRemoting to work around BCL bug when overriding a generic method with generic constraint.
This is useful when you want to force Rhino Mocks to use Remoting proxies (usually it just guess and you don't deal with this). That is needed because at certain cases ( generic methods with generic constraints ) there is a bug in Reflection Emit that generate invalid code. - Mike Nichols has added List.ContainsAll() constraint
- Shawn Neal added the DoNotExpect syntax, which is clearer the Expect.Call().Repeat.Never(), it is certainly shorter.
- Added trace writer with stack trace, should make it easier to track down strange mocking behavior. Now you can just enable logging and see all the method calls that are being made.
- Guido van Loon supplied the Property.AllPropertiesMatch constraints
- Making sure that recorders that wrap recorders will be merged if they contain only one element. Again, this is something that you are not supposed to understand unless you went deep into the code. Suffice to say that the behavior is easier to understand now.
Bugs, annoying bugs, stupid bugs!
- Fixing issue with empty recorders nested in recorders that has expectations. If you don't get that, then rest assure, neither do I.
- Demid Sukhovsky fixed Rhino Mocks support for Out/Ref values using remoting proxies.
- Fixing null reference exception when stubbing a class with protected setter.
- Aaron Jensen fixed the validation message when you expect a method that accept a mock object as a parameter.
- Aaron Jensen also fixed a bunch of my typos.
- Steven Rockarts fixed a bunch more of my typos.
- Fixed an issue with methods returning non primitive value types, such as UInt32
Comments
Could you ship the pdb file as well ?
Indeed; see:
http://blog.softwareishardwork.com/2008/02/debug-vs-release-flavor-and-debug.html
This on is on the house... :)
Too bad that the nasty intellisense bug was not yet fixed by Microsoft, which still results in broken intellisense support in any Rhino.Mocks version > 3.2 (described in the comments here: http://www.ayende.com/Blog/archive/2007/10/27/Using-Expect.Call-void-method.aspx ) :-( Maybe somebody more skillfull tahn me can have a look at this issue. I would be glad to see a workaround in Rhino.Mocks for this specific issue.
Anyways, thanks for your new release Ayende!
Too bad that the nasty intellisense bug was not yet fixed by Microsoft, which still results in broken intellisense support in any Rhino.Mocks version > 3.2 (described in the comments here: http://www.ayende.com/Blog/archive/2007/10/27/Using-Expect.Call-void-method.aspx ) :-( Maybe somebody more skillfull tahn me can have a look at this issue. I would be glad to see a workaround in Rhino.Mocks for this specific issue.
Anyways, thanks for your new release Ayende!
I suspect that one or two people haven't upgraded because 3.3 has the following bug which stops me from mocking wcf services the way i'd like to - it works in 3.1 so i'm sticking with it for now but i'd like to upgrade if you could fix it..
Test method TestMethod1 threw exception: System.InvalidOperationException: The service class of type IServiceClassInterface1Proxy365c436aedac4078959c816454c8e953 both defines a ServiceContract and inherits a ServiceContract from type TIServiceClassInterface1. Contract inheritance can only be used among interface types. If a class is marked with ServiceContractAttribute, it must be the only type in the hierarchy with ServiceContractAttribute. Consider moving the ServiceContractAttribute on type IServiceClassInterface1 to a separate interface that type IServiceClassInterface1 implements..
Thanks
cool-beans,
Can you supply a failing test case?
Great news Oren, you rock!
Hi all,
this is Kirill Osenkov from the Visual Studio C# IDE team at Microsoft. I'd be happy to help you investigate that IntelliSense bug you've mentioned. For a start, I'd need some repro steps - does it repro in a simple Console Application in Visual Studio 2008? Feel free to contact me with any questions.
Thanks for your help,
Kirill
I don't have a vanilla install of VS 2008, and I couldn't repro the issue.
Nevertheless, here is the code that should probably expose it.
Remove the Return() from both methods and see what you get in intellisense
class Program
{
}
public interface IFoo<T>
{
}
Thanks Ayende. I couldn't repro the bug on Visual Studio 2008, so it looks like we've fixed it since 2005. If you do encounter the bug in Visual Studio 2008, please let me know, I'll be happy to investigate.
Thanks,
Kirill
Comment preview