As you might have heard by now, C# 4.0 (or is it just 4?…) comes with a new keyword: dynamic. This means that you could do something like the following:

Simply put, ExpandoObject is a class that allows you to add and remove members at runtime. This allows us to call methods that are resolved at runtime. As such, the previous code will compile.

Just as you can declare methods, you can also declare properties:

This no doubt can come in handy when working with ViewModels and ASP.NET MVC.

However, there is one minor problem with dynamic objects: you lose intellisense, which means that if in your view, instead of typing dynaCustomer.FirstName, you type dynaCustomer.FristName, you won’t get any errors until you run the app.

And that’s where ReSharper can help:

This is the same code, but with ReSharper activated inside Visual Studio 2010! I typed the FirstName property for the first time. After that, I have full intellisense support for it. The same would apply to methods:

That puts dynamic into perspective.

I use a Spanish Keyboard which is kind of a nuisance when developing in C#. It’s mainly due to the key layout for curly braces. Every time you need curly braces, you have to press AltGr (Ctrl+Alt) along with another key. Other annoying keys are the semicolon and the square brackets.

(Image licensed under the Creative Commons Attribution ShareAlike 3.0, obtained from Wikimedia Commons)

So after years of frustration, I finally decided to call it a day. Today I ran into the Microsoft Keyboard Layout Creator which allows you to create custom keyboard layouts. It’s pretty simple to use and extremely flexible since it allows you define dead keys also (which was part of the my problem when attempting to do it manually using the Scancode Maps). You can change key mappings or define a whole new keyboard layout from scratch.

My new mapping is based on the original Spanish layout, switching the key combinations required for curly braces and square brackets. Instead of getting a tilde by default, you now get braces and brackets. If you want the original characters, you need to use AltGr. I’ve switched the semicolon and comma around also. You no longer need to use shift to obtain a semicolon. I’ll see how it works out, although I must admit while writing this post, every time I’ve wanted to insert a comma, I’ve ended up with a ;

The tool creates a convenient executable so that you can install the new mapping on any machine without a lot of fuss. I’m including both the executables (x86, 64bit, etc.) along with the project file to this post. Feel free to use it or adjust it to your own needs. Get it here

I just upgraded to the latest release of StructureMap (2.5) and spent a good portion of time trying to figure out a bug I was having in a complex dependency graph. The original exception is a StructureMap exception, with code 207, which per documentation, you need to look at the inner exception. The problem is that the inner exception isn't awfully helpful:

System.InvalidProgramException : JIT Compiler encountered an internal limitation.

Initially I thought it was related to the WithCtorArg method that allows you to pass in parameters to the constructor, but after stripping everything down to try and come up with a test case, it seems that the issue occurs when you have a class that the container resolves which has a public static property, like so:

   1: public interface ISomeClass

   2: {

   3:     void SomeMethod();

   4: }

   5:  

   6: public class SomeClass : ISomeClass

   7: {

   8:  

   9:     public static int SomeProperty { get; set; }    

  10:  

  11:     public void SomeMethod()

  12:     {

  13:     }

  14:  

  15:  

  16: }

Here's the StructureMap configuration test:

   1: [Fact]

   2: public void TestStructureMap()

   3: {

   4:     ObjectFactory.Initialize( x => x.ForRequestedType<ISomeClass>().TheDefault.Is.OfConcreteType<SomeClass>());

   5:  

   6:     ObjectFactory.GetInstance<ISomeClass>();

   7: }

As soon as you make the property private or make it an instance property, the container resolves fine. I tested the same thing with Unity and there doesn't seem to be an issue.

I tested the same code with 2.4.9 and it seems to work. 

I'll be doing a talk in Belgium next month at the Visual Studio User Group, where I'll be covering topics such as Separation of Concerns, Single Responsibility, Interface Segregation, Dependency Injection and Inversion of Control, along with examples of IoC containers. There's limited space (90) and already 55 signed up, so if you're in or around the neighbourhood, got nothing better to do than here my brag, come along. I think they are organizing a geek dinner afterwards so it should be fun. Although the talk will be in C#, the important things to grasp are the concepts, not the language, be it Visual Basic, Delphi or whatever else (obviously it needs to be a OO language).

Here's an update on the roadmap for Linq2Sql. The post is pretty much confirming that they're killing off the project.

A project we started recently, we had to make a choice of which ORM to use. Since Entity Framework wasn't still up to par (and in certain aspects probably still isn't), and the team had experience with Linq2Sql, we decided to use that. However, from day one, we made a conscientious choice of not leaking anything of L2S into our domain objects.

This meant that we didn't use the L2S objects, but in turn used our own POCO classes. Therefore the sole purpose of L2S was to map data from the DB, what the job of an ORM is. Recently, and before the announcement, we found a lot of shortcomings when working with L2S and aggregate roots (I won't get into the details since Steve is planning a series of posts on the subject and how to handle aggregate roots with the different existing ORM's). We've therefore decided to switch ORMs. The beauty of it is that because of the clear abstraction of L2S, it's going to be very easy to swap out L2S for another ORM.

Now that we have confirmation that L2S isn't going anywhere, if you have issues with the current version and were hoping to get them resolved in a future release, I guess you're out of luck. So the time comes to move on. If you've abstracted well, it shouldn't hurt that much.

Obviously if you don't have issues with L2S and no projections on needing new features, then stick to what you have. "If it ain't broken, don't fix it". But don't start any new projects with it. Even Microsoft don't recommend it anymore.