Wednesday, March 31, 2010

Where C# fails, VB delivers.

Recently I've came across a strange behavior that took me some thinking to work around.

As you may know, my language of choice has been VB for as long as I can remember. However, I, like any good developer, can work just as good in C#. Really, it's no biggie.

Anyway, what I'm talking about here is dynamic type resolution.

For instance let's say we have the following VB program:

Module Program
  Sub Main()
    Dim value As Object = 123
    Format(123)
    Format(value)
  End Sub

  Sub Format(ByVal value As IFormattable)
    Console.WriteLine(value.ToString(Nothing, Nothing))
  End Sub
End Module

When ran, the above program will generate the following output:

123
123

Easy enough, huh?

Now, if we port this program to C# like this:

class Program
{
  static void Main(string[] args)
  {
    object value = 123;
    Format(123);
    Format(value);
  }
  static void Format(IFormattable value)
  {
    Console.WriteLine(value.ToString(null, null));
  }
}

Which is the literal translation of the VB program above, we can't even compile to program, because the C# compiler gives the following errors:

error CS1502: The best overloaded method match for 'DynamicCS.Formatter.Format(System.IFormattable)' has some invalid arguments

error CS1503: Argument '1': cannot convert from 'object' to 'System.IFormattable'

It's the same damn code, how come C# can't convert from object to IFormattable?

Well, the answer is that the C# compiler requires that all types to be known at compile time, rater than establish at runtime.

Sunday, March 14, 2010

Today is a sad day!

It's almost 11:30 pm, March 14th, 2010 when I've got an email from one of the many newsletters I subscribe.

The subject of the email was simply "Puppy", and that belies its true content, that for me was kind of a shock.

Joel is retiring from blogging.

I don't know if any of you know but I've began this site, this little corner in the Internet, because of Joel.

I've reading his columns, his posts, his insights on software development, business conduction, and many other subjects and little stuff he felt like sharing with the world.

And now, this is about to change.

I don't really know his reasons for doing this, although he did try to explain on his post. Whatever they might be, they are his own, and we must respect.

Anyway, I just wanted to vent it out of my chest.

Wednesday, March 03, 2010

VSTO Differences in VS2010 RC1

Yesterday I restarted working on an Oulook Add-in I'm cooking up for Office 2007 that I began developing in VS2010 Beta 2, and I got pissed when the code that was running quite well, simply gave me compiler errors.

Well apparently there were some changes from Beta 2 to RC 1 regarding the development of Office add-ins.

The main problem, for me, was that the class Microsoft.Office.Tools.CollectionBase<T> is gone so, any class that derives from it needed to be updated manually, and the affected classes were ThisFormRegionCollection and WindowFormRegionCollection that were changed from being a derived class of CollectionBase<Microsoft.Office.Tools.Outlook.IFormRegion> to be a derived class of Microsoft.Office.Tools.Outlook.FormRegionCollectionBase.

After changing this the code was recompiled successfully.

Building AsmMeta - follow up

A couple days ago I've written about the error I was getting when building an Windows Mobile control with design time capabilities. What I forgot to write about was the solution for the problem:

The problem occurred because in one of my classes was inheriting from a ReadOnlyCollection and this is not supported by the genasm.

As it's stated in this Microsoft Forum Thread.

So to work around this problem, I moved the classes that didn't require design time attributes to another assembly and the projects compiled just fine.