Omer van Kloeten's .NET Zen

Programming is life, the rest is mere details

News

Note: This blog has moved to omervk.wordpress.com.

Omer van Kloeten's Facebook profile

Omer has been professionally developing applications over the past 8 years, both at the IDF’s IT corps and later at the Sela Technology Center, but has had the programming bug ever since he can remember himself.
As a senior developer at NuConomy, a leading web analytics and advertising startup, he leads a wide range of technologies for its flagship products.

Get Firefox


powered by Dapper 

.NET Resources

Articles :: CodeDom

Articles :: nGineer

Culture

Projects

The Death of System.DateTime?

It’s been a few months since I started getting acquainted with the System.DateTimeOffset type and I can honestly say I don’t see any reason to use System.DateTime anymore.

I’ve even gone as far as ask whether anyone knew when I would rather use DateTime over DateTimeOffset. The responses I got were along the lines of ‘backwards compatibility’ or ‘when you need an abstract time’. My recommendation is that if you haven’t yet looked at the type, go do it now and after that, start using it.

So what is this DateTimeOffset? When representing a date/time, especially in an internationally-faced system, you have to include a time-zone. DateTime did a very poor job handling time-zones, like being insensitive to changes. DateTimeOffset is the exact same thing as DateTime, only it takes heed of time-zones. For instance, comparing two DateTimeOffsets with the same UTC time in different time-zones will result in equality.
Moreover, DateTime also had only three modes: Local, UTC and Unspecified, whereas DateTimeOffset has an Offset property, allowing you to create dates in any time-zone you like.

Things to note:

  1. DateTime can be implicitly converted to DateTimeOffset, but not vice-versa. To do that, you would have to use DateTimeOffset’s DateTime property.
    When converting this way, the DateTime’s kind will always be Unspecified.
    DateTimeOffset dateTimeOffset = DateTimeOffset.UtcNow;
    DateTime dateTime = dateTimeOffset.DateTime;
  2. When parsing a DateTimeOffset, note that you can specify AssumeUniversal and AssumeLocal using the DateTimeStyles enum. These come in handy when the string you’re parsing has no time-zone data.
    if (!DateTimeOffset.TryParse(myDateString, CultureInfo.InvariantCulture.DateTimeFormat, DateTimeStyles.AssumeUniversal, out dateTimeOffset))
        dateTimeOffset = default(DateTimeOffset);
  3. It is a best practice to store all of your dates as UTC in the database, regardless of the physical location of your users / servers. When doing this, be sure to manually change your DateTimeOffset objects to UTC using ToUniversalTime and only then use the DateTime property as I have previously noted.
    SaveTimeToDatabase(dateTimeOffset.ToUniversalTime().DateTime);
    Note that you do not need to convert DateTimeOffset objects to any time-zone to do calculations / comparisons. The only time you need to convert them to a time-zone is for displaying them to the user.
  4. If you want to store a user’s time-zone (on a database that doesn’t support date/times with time-zones), it would be best to have a translation table and use the TimeZoneInfo class’s Ids (for instance: TimeZoneInfo.Local.Id). Then you could use TimeZoneInfo.FindSystemTimeZoneById to translate that value to a TimeZoneInfo and use that object’s BaseUtcOffset property to get the difference from UTC.
    This may seem a bit cumbersome, but considering the fact that time-zones change due to daylight savings time, you can’t just store the difference from UTC and would be better suited allowing Windows to take care of these issues for you.
    Here’s a sample of this method of conversion:
    string id = "Israel Standard Time";
    DateTimeOffset utcnow = DateTimeOffset.UtcNow;
    
    DateTimeOffset now = utcnow.ToOffset(TimeZoneInfo.FindSystemTimeZoneById(id).BaseUtcOffset);

Side note: When storing these in the database, it would be prudent to use SQL Server 2008’s datetimeoffset type, which is the equivalent of DateTimeOffset and takes care of the time-zones in the same manner.

My View of C# 4.0

I've known a bit about C# 4.0 for a while now and have had time to think about it. I've just re-read the New features in C# 4.0 paper published by Microsoft and would like to offer the following critique of the language's new features:

Dynamic Lookup

Microsoft PDC 2008 by Manohar Dasari, CC-BYThis feature just makes me cringe, just like anonymous methods made me cringe when they were introduced in C# 2.0. To this day, I hardly use them, as they always feel like a kludge to me (lambda expressions fixed that).
The dynamic keyword is as open to abuse as anything could be. It takes the principles of static typing and throws the baby out with the bathwater.

What is wrong with it

When looked at initially, the dynamic keyword is great, because it simplifies and speeds up what is usually done with Reflection and Primary Interop Assemblies, both in the aspect of development times and the aspect of run time. Unfortunately, too much of a good thing is bad for you. Imagine the following:

public dynamic GetCustomer()
{
    // mystery...
}

What do we have here then? I don't know and neither does IntelliSense? I guess we'll have to go with trial and error.
I admit this is quite the dramatization, but you get my point: it's ripe for abusing an otherwise perfectly fine static syntax.

Moreover, the dynamic keyword's syntax does what no other feature of C# has ever done - it breaks existing syntax. Should I define in C# 3.0 a type named dynamic, the following piece of code will take a whole different meaning in C# 4.0:

public dynamic GetCustomer()
{
    dynamic customer = GetCustomerCOMObject();
    return customer;
}
How it can be fixed

Using the dynamic keyword is actually a built-in form of Duck Typing. The idea is good and should be introduced into the language, but I'd like to suggest a different way of doing it:

public ICustomer GetCustomer()
{
    dynamic ICustomer customer = GetCustomerCOMObject();
    return customer;
}

Here, what I get back is a dynamic dispatch object that must adhere to a specific interface. This means that the object graph is checked for conformity against ICustomer the moment it is cast in the dynamic scope (i.e. returned from GetCustomerCOMObject) and is from this moment on a typed object with dynamic dispatch under the hood. From this moment on, we couldn't care less about whether this object uses dynamic dispatch or not, since we now treat it as a POCO.
This, along with removing of the ability to send dynamic dispatch objects through the call-stack (as parameters and return types), bringing them to the level of anonymous types, will help stop the deterioration of C# into a dynamic language.

Named and Optional Arguments

Untitled by Long Zheng, CC-BY-NC-SAThis is just silly. Really, this looks like some people cried "we don't like overloads" hard enough and got some VB into the C# the rest of us liked the way it was. If you want to initialize your method with some of the parameters, use a builder pattern with an object initializer instead.

Here, I'll take the sample at the bottom of page 6 and fix it, C# 3.0 style:

public void M(int x, MBuilder builder);

public void M(int x)
{
    this.M(x, new MBuilder());
}

public class MBuilder
{
    public MBuilder() { this.Y = 5; this.Z = 7; }
    public int Y { get; set; }
    public int Z { get; set; }
}

M(1, new MBuilder { Y = 2, Z = 3 }); // ordinary call of M
M(1, new MBuilder { Y = 2 });        // omitting z – equivalent to M(1, 2, 7)
M(1);                                // omitting both y and z – equivalent to M(1, 5, 7)

Yes, I do realize it's mainly for COM interop, but most people will just get either confused by all the syntax, abuse it or simply forget it ever existed.

What is wrong with it

It exists.

How it can be fixed

Remove it from C#. There - fixed.
If you want optional parameters in your COM interop calls, just implement the correct overloads in the interface you create for use with the dynamic keyword (see my suggestion for dynamic lookups) and the binding will be done at run time by the parameter names.

Variance, Covariance and Contravariance

These three features are long overdue and finally make an appearance in the language. It's a great feature and I would love to integrate it into my code as soon as I possibly can.
I would love to know if there are plans to not only include reference conversions, but also the implicit and explicit conversion operators as qualifiers for VC&C.

What is wrong with it

Anders Heilberg at book signing by DBegley, CC-BYAlthough Variance is implicit, the others are explicit. Using the Type<in T> / Type<out T> notation is good for being explicit (for instance when you expect your interface to be expanded in the future), but it doesn't have to be and can become a bit annoying over time.

How it can be fixed

The compiler can very easily infer the fact that your interface is either input-only or output-only and mark it as such for you. Language-wise, the explicit version should be kept available, for when you want to prevent someone (or yourself) from mistakenly adding a new method that breaks the your input / output only design.

Summary

It looks to me like the team behind C# is going in the wrong direction (DLR) instead of the right direction (Spec#), slowly turning C# into a dynamic language. It looks like all of this is done for the sake of easy interop with dynamic languages and COM objects. It looks as though the designers have succumbed to peer pressure. There are so many features missing from C# and the above are nowhere near the top of my list.

I can only hope someone is listening.

Posted: Oct 29 2008, 02:16 AM by Omer van Kloeten | with 27 comment(s)
Filed under:
Microsoft Israel's Developers' Academy #3

Voting has been open for a few days now for which lectures will be featured at the next Microsoft Developers' Academy. The event is the second most important event for Microsoft-platform-developers in Israel, surpassed only by the biennial Tech-Ed Israel.

Among some very interesting lectures I would love to see, I've suggested a lecture myself. Here's its abstract:

A Deep Dive into LINQ

Many developers already use LINQ on a daily basis, but most only scratch the surface of what’s possible. In this session we will dive more deeply into LINQ and see how it works behind the scenes, share tips, tricks and common pitfalls.

While most of the lecture's structure is already defined in my head, I'd love to hear from you what topics you would like to see covered, either from the topics covered in my blog's posts or from your own experience.

Go vote and I'll be seeing you there! :)

Visual Studio 2008 Load Testing Checklist

frustrated by Jon Watson, CC-BY-NC-SA After a couple of days of trying to run a load test for a web service on several agents via Visual Studio 2008, I come out much wiser and with a few new bald-spots, where hair I pulled out in the process used to be.

I got a few errors whose messages have nothing to do with what really happened, so here's a quick checklist:

  • Try restarting the agent service.
  • Re-register the agent using AgentConfigUtil and then restart the agent service.
  • Try restarting the controller service.
  • Are you using a trial version of Visual Studio Team System? If so, it may have expired.
  • Are all of your agents and controller on the same version?
    Check that the file Microsoft.VisualStudio.QualityTools.LoadTestFramework.dll is the same version on all of your computers (more information). Its original version is 9.0.21022.8, SP1's version is 9.0.30729.1. If you installed the trial from Microsoft's site, your version is pre-SP1.
    If any of the agents differs from the controller, you will not be able to use them and will see them as Disconnected in the Administer Test Controllers dialog.
  • Are you using SQL Server as a store for the results?
    • Does the user the service runs as have permissions to the SQL Server database?
      You can see which user is used to access the store from Visual Studio's Menu Test -> Administer Test Controllers.
    • If you're getting login errors, check that the SQL Server allows remote connections. If it does, consider using a SQL Server user instead of Windows Authentication. Remember to make sure the SQL Server allows both types of connections (Mixed Mode) before attempting this.
    • Make sure the computer from which the SQL Server is running has an exception for incoming connections on TCP port 1443.
  • Using the trial version of the agents? Getting "The Visual Studio Team Test Load Agent license has expired" way before your 90 day trial period has elapsed? You've probably hit the 25 tests mark (note that the tests are per-CPU, rather than per-computer).
    You can work around this if you change the user running the service.

Around that time I decided I've had enough with all this trial stuff. I was thinking about purchasing licenses, but then I took a look and found that you can only use load agents when you've got a Volume License!

At that point, I went and just ran the test on a few computers at once.

    Extending The Partial Classes of Stored Procedures' Results in LINQ to SQL

    Original: Where do we go next? by Anke L, CC-BY-NC-SA One of the nice things about LINQ to SQL is the ability to extend the types of the generated entities. Another nice thing is being able to get typed results from stored procedures. Let's try and combine the two together.

    We'll take the following generated code for instance:

    public partial class GetStuffResult
    {

    private int _Id;

    private string _Name;

    public GetStuffResult()
    {
    }

    [Column(Storage="_Id", DbType="INT NOT NULL")]
    public int Id
    {
    get
    {
    return this._Id;
    }
    set
    {
    if ((this._Id != value))
    {
    this._Id = value;
    }
    }
    }

    [Column(Storage="_Name", DbType="NVarChar(100)")]
    public string Name
    {
    get
    {
    return this._Name;
    }
    set
    {
    if ((this._Name != value))
    {
    this._Name = value;
    }
    }
    }
    }

    I would like to extend it by adding a new property to it, named TranslatedId, which translates the returned Id to and from a Guid:

    partial class GetStuffResult
    {
    public Guid TranslatedId
    {
    get
    {
    return Translator.GetGuid(this.Id);
    }
    set
    {
    this.ProjectId = Translator.GetInt(value);
    }
    }
    }

    Translator's two methods translate between the integer id and the Guid id. Note that 0 translates to and from an empty Guid.

    I'll try to run it and will find out that all of my Ids are 0. Why is that?

    Apparently, when running a stored procedure in LINQ to SQL, it requires all of the properties defined on the class to have both getters and setters (which means you can not write read-only properties in the partial class) and sets all non-result (i.e. non-generated) properties to their default values. This means that although the real Id gets selected from the database, TranslatedId gets set to an empty Guid immediately afterwards, which in turn overrides Id to 0.

    To work around this, we have to apply a dirty little hack:

    partial class GetStuffResult
    {
    private Guid dupe;

    [Column(Storage = "dupe")]
    public Guid TranslatedId
    {
    get
    {
    return Translator.GetGuid(this.Id);
    }
    set
    {
    this.ProjectId = Translator.GetInt(value);
    }
    }
    }

    This is pretty horrible, but what it does is direct LINQ to SQL to set the default value into the property's storage field, which is some dupe field, instead of into the property itself. Now the field's value will be reset and not the property's. Note that the dupe field's type should be the same as the property's type.

    Yes, it's ugly, but this is the only workaround I found. If anyone knows of any other workaround or solution to this problem, I'd love to hear it.

    [Original image used: Where do we go next?]

    Announcing New C# 4.0 LINQ Features and Book

    * Fabrice Marguerie, co-author of LINQ In Action, asked me to clarify that this post has absolutely nothing to do with their book and is simply meant in jest *

    LINQ has been around for quite a while, making our lives easier with its short, declarative syntax. During talks in closed sessions, the persons behind C# have come up with some great plans for its next version, including some vast improvements to LINQ. The team wanted to make everyone's lives even better by introducing some ground-breaking features to it.

    I'd like to introduce, out of those finalized or at the final draft stage, some of the new keywords that have been introduced to the language with regards to LINQ and by doing so, expose the reader to this new, exciting technology.

    fine

    Many of the lines of code incorporated into LINQ are about variable validation. How many times have you had to write pieces of code like this:

    var values = from n in numbers
    where n > 0 && n < 10
    select n;

    This piece of code is very trivial and the compiler is smart enough to understand it on its own. From C# 4.0, the fine keyword is introduced and the above query will be replaced with:

    var values = from n in numbers
    where n is fine
    select n;

     

    some

    Most LINQ queries do not iterate over an entire enumeration. Some filter out results, some use Take, Skip and other methods in order to run on only a subset of the elements. Since this is an extremely common scenario, the team has decided to integrate it into the language using the new some keyword:

    var values = from n in some numbers
    select n;

    This is complemented with the new most keyword, which is like some, only it takes more elements.

    somewhere

    Global Warming vs. LINQ from Clauses The from clause is known to all who use LINQ, as it indicates the source of the data. Since this clause is a recurring pattern (statistical surveys have shown it to occur 99% of the time, allowing for a 4% standard deviation), the team behind the new language features has decided to cut it out, thus removing unnecessary verbosity from the language. This, in turn, will cause less characters to be written and rewritten, meaning less keystrokes, less keyboard wear, less purchases of new keyboards, leading to prevention of global warming, a goal near to Microsoft's heart. You can see Microsoft's predictions for this in the graph to the right.

    This is possible due to the new somewhere keyword, as described below:

    var values = from somewhere
    select n;

    This feature relies heavily upon the newly introduced Type Inference Transfer System (abbreviated MANTA), a technology recently demonstrated by Microsoft Research.

    The Book

    LINQ InactionI've long since wanted to write a book about something. Since this is just the tip of the iceberg, I've decided to write my book about this subject. It will contain most of what I know (hey, I still need to speak about something at conferences and release a second edition some day, right?) about the new language. I think that with all of the new features, making our lives as developers that much easier, I've picked an appropriate title.

    Here's an excerpt from the introduction:

    Recent advances in compilation technologies have brought with them less need for verbosity. In its stead come smart compilers, which infer much of the work for the developer. With such technology, there's not a lot you, as a developer, need to do anymore. You can simply write a short statement, validate its correctness, check the code in and go home for the day.

    Welcome to the world of tomorrow. Put your feet up.

    Here's the layout of the book, as I plan it:

    1. Introduction
    2. New Features in LINQ

    What else would you like to see in the book? Let me know and I might just send you a copy of the rough draft for review once I finish it.

    Posted: Aug 29 2008, 01:12 PM by Omer van Kloeten | with 12 comment(s)
    Filed under: ,
    Throw Before You Yield

    In a comment left by Bart De Smet, he pointed out that I failed to address the fact that the execution of all "yielding" methods is deferred.

    For instance, when running the following code, no exceptions will be thrown:

    int[] arr = null;
    var copy = arr.Enumerate();



    // ...

    static IEnumerable<T> Enumerate<T>(this IEnumerable<T> enumeration)
    {
    // Check to see that enumeration is not null
    if (enumeration == null)
    throw new ArgumentNullException("enumeration");

    foreach (var item in enumeration)
    {
    yield return item;
    }
    }

    This is because the first time the code from the method will run will be after there a call to copy's GetEnumerator(), followed by a call to that object's MoveNext() method has been made (i.e. when we enumerate over copy).

    To overcome this problem, we'll change the code slightly:

    static IEnumerable<T> Enumerate<T>(this IEnumerable<T> enumeration)
    {
    // Check to see that enumeration is not null
    if (enumeration == null)
    throw new ArgumentNullException("enumeration");

    return EnumerateCore(enumeration);
    }

    private static IEnumerable<T> EnumerateCore<T>(IEnumerable<T> enumeration)
    {
    foreach (var item in enumeration)
    {
    yield return item;
    }
    }

    Now a NullReferenceException will immediately be thrown out of Enumerate, since the "unyielding" method will first run the code and then defer-call to the "yielding" method. This helps our "yielding" methods adhere to the principal of fail-fast.

    Posted: Aug 25 2008, 10:23 PM by Omer van Kloeten | with 3 comment(s)
    Filed under:
    MSDN Wiki?

    Instructional Objectives by Davina DeVries, CC-BY I just love the fact that there's a "Community Content" section to the MSDN documentation. I just found out that there's an undocumented exception coming from the System.Net.Mail.MailMessage.Subject property, I browsed to the relevant MSDN page and simply added a line saying so.

    It's a nice copy of the features from PHP's Documentation, but about 10 years too late, and also, mind you, not a Wiki at all. It's comments. In a real Wiki, my corrections to the documentation would be displayed inline with the original documentation. You know, like Wikipedia. Dear Microsoft, please turn it into a real Wiki, at which time your documentation will retain its relevance for me.

    On a side note, does anyone know of an add-in for Visual Studio that replaces F1 to a call to Google in my default browser?

    Pitfall: Static Field Inline Initialization Order of Execution
    Lean by Katayun, CC-BY-NC-SA Here's something I fell into today. You have a class that has some members that need to be calculated once. So you use static readonly fields. One of those members is a calculation of some of those members. Take the following code for instance:
    public class StaticDemo
    {
        static readonly int Sum = A + B;
        static readonly int A = Calculator.GetA();
        static readonly int B = Calculator.GetB();
    }

    This code will initialize A and B from the Calculator class and initialize Sum from the sum of A and B. However, when you run this code, Sum will equal 0, no matter what A or B are.

    Why is this? Apparently, when initializing static fields inline, the order of execution is from top to bottom, regardless of dependencies. Trying to use the same method to initialize an instance field will result in the error A field initializer cannot reference the non-static field, method, or property.

    So how do we solve this, you ask?

    public class StaticDemo
    {
        static readonly int A = Calculator.GetA();
        static readonly int B = Calculator.GetB();
    static readonly int Sum = A + B;
    }
    Now Sum will really equal the sum of A and B. Simple, but a sure-fire pitfall if you don't know it.
    Posted: Aug 19 2008, 05:09 PM by Omer van Kloeten | with 8 comment(s)
    Filed under:
    Extension Methods Roundup: Intersect, Union, AsNullable and GroupEvery

    Here we go with the third installment of the Extension Method Roundup. The reason behind these 'code dumps' is that LINQ is a central part of my coding and always find new problems I want to find elegant solutions to. Hope these prove as useful to you as they do to me.

    Intersect / Union

    Again, shorthand for when you have Enumerable of Enumerable of T and you simply want to intersect or union all of the enumerations in one single call.

    public static IEnumerable<T> Intersect<T>(this IEnumerable<IEnumerable<T>> enumeration)
    {
        // Check to see that enumeration is not null
        if (enumeration == null)
            throw new ArgumentNullException("enumeration");
    
        IEnumerable<T> returnValue = null;
    
        foreach (var e in enumeration)
        {
            if (returnValue != null)
                returnValue = e;
            else
                returnValue = returnValue.Intersect(e);
        }
    
        return returnValue;
    }
    
    public static IEnumerable<T> Union<T>(this IEnumerable<IEnumerable<T>> enumeration)
    {
        // Check to see that enumeration is not null
        if (enumeration == null)
            throw new ArgumentNullException("enumeration");
    
        IEnumerable<T> returnValue = null;
    
        foreach (var e in enumeration)
        {
            if (returnValue != null)
                returnValue = e;
            else
                returnValue = returnValue.Union(e);
        }
    
        return returnValue;
    }

    AsNullable

    I was always missing this method, to coincide with the Cast and OfType methods.

    public static IEnumerable<T?> AsNullable<T>(this IEnumerable<T> enumeration)
        where T : struct
    {
        return from item in enumeration
               select new Nullable<T>(item);
    }

    GroupEvery

    This takes count items from an enumeration and groups them into a single array.

    public static IEnumerable<T[]> GroupEvery<T>(this IEnumerable<T> enumeration, int count)
    {
        // Check to see that enumeration is not null
        if (enumeration == null)
            throw new ArgumentNullException("enumeration");
    
        if (count <= 0)
            throw new ArgumentOutOfRangeException("count");
    
        int current = 0;
        T[] array = new T[count];
    
        foreach (var item in enumeration)
        {
            array[current++] = item;
    
            if (current == count)
            {
                yield return array;
                current = 0;
                array = new T[count];
            }
        }
    
        if (current != 0)
        {
            yield return array;
        }
    }

    I've also gone and updated my LINQ Extensions project on CodePlex with everything I've published since the last update. You're welcome to download and fiddle with it. :)

    More Posts « Previous page - Next page »