Daddy Starr has reponded to the latest discussion on TFS vs a mixture of tools, he points out that something that was missing from the discussion is...

I agree with the first point, but disagree with the second. I can get this from a a set of components that I assemble together. It is not trivial, but it is not very hard either, and it is something that you need to do anyway.

Agreed, the discussion was being side tracked because I use OSS tools and gave examples from them, but I was mostly talking about the general idea of separate tools that collaborate for a cohesive whole.

And didn't you just lose the integrated benefits? Yes, I am aware that you can use CC.Net to work against TFS, and you can use NUnit to run tests, etc. But those aren't integrated into the product, you need to "cobble together" a solution that would give their output back into the system. How do you track build results now? How do you go from a build to the change set that triggered it?

The part that I seem to fail to explain is that I have looked at TFS, saw that it had major failings in Unit Testing, Continious Integration and Source Control, once I saw that, I was no longer interested in the integrated package. And if I am not interested in the integrated package, what does TFS has to offer me? Not much that I can't get from somewhere else, frankly.

Remind me not to mention the Vi vs. Emacs discussion, then :-)

Dave Laribee had a great post where he details some of the qualities of an open minded developer. He also coined the term ALT.NET.

A few others has taken this idea and extedned and bulleted it. I really don't like it. I have two main issues with making this idea into a series of boolean bullet points.

Saying things like "An ALT.NET developer would be using Castle Windsor before Enterprise Libraries ObjectBuilder.", or "An ALT.NET developer was using NHibernate before the Entity Framework." is giving the wrong impression. It gives the impression of you are either with us (good) and against us (bad). And you must follow Our (notice the royality speak) way and no other.

The other objection is that it is focusing on tools and not on a mind set. The way I see it, this is much more about keeping your head open to new approach and ideas, regardless of where they come from. In short, I really like the ideas and concepts that Dave presents, I don't want the idea to turn into "A .NET developers that seeks to use non Microsoft technologies." I would much rather it be "A developer that seeks to find the best tools and practices, and judge them on merit."

We as an industry has enough problems with the "We Are A Microsoft Shop, Do Not Write Non Microsoft Certified Code!" apprach, we don't need it in the other direction. Prejudice can go both ways, after all, and reverse racism is just as unacceptable.

When comparing NHibernate to the Entity Framework, I found two places that the Entity Framework could do things that were difficult to do with NHibernate. One was multi table entities, that was already taken care of, thanks to a patch by Karl Chu.

The second is parameterized projections. I will fix that if you can figure out what this means, and when you would like to use that.

New features:

• A old new syntax that is more explicit about the record replay model, courtesy of James Kovacs:
  

  MockRepository mockRepository;

  mockRepository = new MockRepository();

  IFoo mockedFoo = mockRepository.CreateMock<IFoo>();

  using (mockRepository.Record())

  {

         Expect.Call(mockedFoo.Bar()).Return(42);

  }

  using (mockRepository.Playback())

  {

         Fooz fooz = new Fooz(mockedFoo);

         fooz.Barz();

  }

• Applied patch from Ross Beehler, adding more smarts to Validate.ArgsEqual

Bug fixes:

• Fixing an issue where virtual method calls in partial mocks ctors were not called.

• Fixing an issue with mocking objects with protected internal abstract methods

I just got a bug report for Rhino Mocks from Kevin Miller. Those are not that common, but not very rare. That one came with a test case, which is also fairly common for bug reports (after all, Rhino Mocks is used in TDD scenarios :-) ).

I gave it a glance, saw that it had a lot of stuff that I needed to read, and started to put it on my ToDo list. Then I looked at the attached file name. For no particular reason, I have this convention of putting all the bug reports for Rhino Mocks using "FieldProblem_[ReporterFirstName]". The file that kevin sent me was named "FieldProblem_Kevin.cs"

That was interesting enough that I fired opened the file right away, saw that this file could simply be dragged into the Rhino Mocks solution, with no extra modifications needed (namespaces, naming, etc). That was enough for me to follow up immediately. Luckily, this was something that I was able to quickly fix.