YEEEEEEEEEEEEHA the spelling checker didn’t like that one), here are some of the new features in VB 10.
And yes, I did sound happy there, because some of these features are really not optional but much needed. Like the multi-line lambda and the sub lambda.

You can find the whole video on Channel9

Multi-line lambdas will look like this

Or like this

Now this will also be possible. And I’m very happy about that.

They will also support auto properties and collection initializers, neither of which I really needed.

I’m so happy, I think I will stick with VB for a while. Although all the catching up to C# thing is annoying. I just hope it doesn’t become a VS 2011 or later version. Let’s make it a VS 2010 that came out in 2009 version shall we?

And here is some other stuff that should be possible.

Info found after some random surfing on StackOverflow

There is no bug in Rhino mocks if that’s what you’re thinking. Rhino mocks 3.5 just uses things that VB.Net 9.0 can’t use and that can be frustrating. I wonder what possessed them to do it like that?

So let me tell the story.

I got a service and a repository, the service calls the repo.

Repo interface:

The repo implementation:

The service interface:

The service implementation:

And now we want to test it.

First, we test the service’s findall method. We mock out the repo and see if the repo was called.

This works just fine.

Now I want to see if the update method is also used as it should be, so I write this:

But that gives me an error “Expression does not produce a value.". Mmmm, you can find an explanation for that here. And the solutions is there as well. The solution is, however, a bit clunky, as he says.

So in the end you could do this:

Which solve the problem, more or less.

So, last week Ayende made a new version of Rhino Mocks available, namely version 3.5. He made a post on what is new and shiny, but I would like to look at what the new AAA syntax has in store for us VB.Net users.

And I want to tell you how it used to look and how it looks now.

This is the old version, works with Rhino mocks 3.4.

Ok, so we notice the use of _mocker and DynamicMock to create our Mock objects and then we set our expectations, then we do a replayall and execute the methods under test. When the test is done the verifyall is executed which looks if our expectations are met.

Now we switch to Rhino mocks 3.5 and see that we get an error on Expect saying that the signature is not correct. No worry this is because it is choosing the wrong Expect. It is namely trying to use the extension method there. Just add Rhino.Mocks. before the Expect and all is well again. Look how the imports doesn’t do the same thing.

And now on to the new.

Look at how the _mocker.DynamicMock are replaced by MockRepository.GenerateMock and how the _mocker object has disappeared all together. The Expect.Call’s have been replaced with Object.Stub methods. And the ReplayAll and VerifyAll are now gone. Overall, a bit simpler and more meaningful.

Here is another good article about the use of AAA and Rhino mocks but then in C#.

And it only goes to show that even the smartest and best people don’t get it right the first time .

Ayende asked to add this to his wiki and so I did http://ayende.com/wiki/Rhino+mocks+3.5+and+VB.Net+the+AAA+syntax.ashx

I’m using the SVN version for this.

Lets give an example of how to do this.

First we create a few interfaces.

as we can see ITest has a property Person of type IPerson. Ideally we would like to inject the IPerson.

Then we have the concrete classes.

Now I want to inject the Person that I have already made with structureMap.

The first line makes a new registry.
The second line adds a Iperson to the registry with as concretetype Person that is also the default for IPerson with a name of default.
The third line adds an ITest to the registry with as concretetype Test that is also the default for ITest with a name of default and a setterdepency on IPerson that wants the default implementation of IPerson which we declared in line 2.
Line 4 creates the container.

Having done all this we can now see the result via console.writeline (our favorite testrunner ;-))

This should give the following as a result.

test
Person
Person

Simple enough. Very usefull for when you want to inject your observable into a usercontrol. Usercontrols should have a default constructor for the designer, actually it is also the only constructor because the designer can have a difficult time otherwise. This is actually the only reason why I use Setterinjection instead of constructorinjection.

There used to be time when you would configure StructureMap this way

and then this to get your implementation

Fine that all worked nice and dandy but it had a drawback. Structuremapconfiguration was static/shared. This meant that this.

would lead to an error because you could not add classes to structuremap once objectfactory.getinstance was called. But Jeremy and his compadres (sorry musketeers) to the rescue. In the new svn version (not version 2.4.9 apparently) you can do this.

Or something equally brilliant. You can now add things to the container even after calling resolve.

You can find more of this Using the StructureMap Container independently of ObjectFactory by Jeremy and Comparing .NET DI (IoC) Frameworks, Part 2 by Andrey Shchekin