Best Practices in DI/IoC
Interesting discussion about best practices in Dependency Injection (DI/IoC). There’s a consensus that injecting the container is usually wrong. Basic design still prevails, objects should have specific responsibilities and you’ll stay out of trouble.
FX Cop has rules to help out too:
This MVVM toolkit got us talking about VB.
VB is not our favorite language, but a few came out against being against. It’s too verbose for most of us.
‘Beep’ is a keyword, so maybe its not all bad.
What’s up with no edit & continue support for methods with Lambda Expressions(mostly from LINQ queries).
Error 7 Modifying a ‘method’ which contains a lambda expression will prevent the debug session from continuing while Edit and Continue is enabled.
Originally this post was going to be “LINQ Vs. Edit and Continue”, but then I found this article on MSDN saying how it works just fine in Visual Basic. Visual Basic! WTF!!!
The details for VB are a little cagey though:
You can add or remove code before the LINQ statement…. Your Visual Basic debugging experience for non-LINQ code remains the same as it was before LINQ was introduced.
Does this mean if you add or remove code after a LINQ statement it stops edit and continue, or does this mean MSDN needs a better editorial staff? The “before” seems to cast doubt on the statement that “debugging experience for non-LINQ code remains the same ” Not that I really care since I like my languages with curly brackets.
If you want to know what you can’t do in C# edit and continue, read this article. I personally have no interest in what I can’t do. I only want to know when I’ll be able to do it and I couldn’t find any articles on that. I heard from a friend that its not fixed in C# 4.0. 😦
LINQ is too good to give up, but this is really getting annoying.
I’m almost (getting this close) ready to make my own solution, or horrors, switching to VB.