Is a given Field one of SharePoint’s Built-In Field?

We struggle with this issue on my current project. The issue itself is rather trivial: we have a field (actually, the Guid of a field) and we want to know if it is one of SharePoint’s built-in field or if it is a custom field from our application.

Now, as our application runs on MOSS 2007, there are two kind of built-in fields: those of WSS 3.0 and those of MOSS 2007. For WSS 3.0 fields, there is a class named SPBuiltInFieldId that has all the built-in fields’ guids as public fields and the class even has a static method Contains that allows to quickly find out if the field is built-in from WSS 3.0 or not.

For MOSS 2007 fields, there is the Microsoft.SharePoint.Publishing.FieldId class that has all the built-in fields’ Guids as public properties, but unfortunately does not have a “Contains” method.

So how are we going to find out? Obviously, we are not going to compare against all the properties of the FieldId class… No, let’s do this the clean way: make use reflection to build up a Dictionnary with all the Guids then we’ll use that table to check if our field is in it or not!

static IDictionary<Guid, bool> PublishingBuildInFields { get; set; }

static Program()
{
    Type type = typeof(Microsoft.SharePoint.Publishing.FieldId);

    var propsInfoArray = type.GetProperties(BindingFlags.Static | BindingFlags.Public);

    PublishingBuildInFields = propsInfoArray
        .Select(prop => (Guid)prop.GetValue(null, null))
        .ToDictionary(g => g, g => true);
}

bool IsSPBuiltInField(SPField field)
{
    return SPBuiltInFieldId.Contains(field.Id)
        || PublishingBuildInFields.ContainsKey(field.Id);
}

Now, one interesting detail is that ToDictionary uses immediate execution, so we are sure to execute reflection calls only once, during the static constructor’s execution. This is important, because if we just built a sequence with Select, every time we could access that sequence the reflection code would execute, which is not a good idea in most cases.

Update: follow up here.

January 30, 2011 | Tags: , , | 1 Comment 

Windows Live Logout Failure

A little digression here. This morning, I clicked on the “Logout” button on Windows Live, and received this message:

WindowsLiveLogoutFail

Not only it asks me to delete the cookies from my browser myself, but the list of site he successfully logged me out off is weird, to say the least.

Oh well…

December 9, 2010 | Tags: | Leave a Comment 

Overload Resolution and Covariance

As of C# 4.0, generics support covariance and contravariance. I won’t talke about contravariance in the post, however.

To sum it up quickly, covariance enables implicit conversion of a generic collection of type T to the same generic collection of a type that derives from T. In short:

IEnumerable<Object> list = new List<String>().AsEnumerable();

This means that as of now, any method that accepts something like IEnumerable<Object> can accept an IEnumerable<String> as well. This changes the overload resolution mechanism:

class A { }
class B : A { }

class T
{
    internal void Foo(IEnumerable<B> sequence)
    {
        Console.WriteLine("In T.Foo.B");
    }
}

class U : T
{
    internal void Foo(IEnumerable<A> sequence)
    {
        Console.WriteLine("In U.Foo.A");
    }
}

In the following code, how does the method resolution changes?

U u = new U();

var l = new List<A>();
var m = new List<B>();

u.Foo(l);
u.Foo(m);

If ran in Visual Studio as a .NET 3.5 application, here is the result:

Overload35

If ran in Visual Studio as a .NET 4.0 application, here is the result:

Overload40

Prior to C# 4.0, U.Foo was not a candidate for a call using a generic collection of B. However, with covariance, it is, hence the different result. So, this is no breaking change, but the behavior of an application might be affected.

December 1, 2010 | Tags: , , | Leave a Comment 

The Misunderstood var Keyword

I find amazing how the var keyword introduced in C# 3.0 is misunderstood.

The web is full of questions asking what are the performances implications of using var, of how var is not type safe and other completely false statements.

Also, one a day, I had a discussion with colleagues that argued that if I was using var, I could also use Object as the type for all the variables and then cast everywhere.

I don’t know why the var appears so misleading. I find it very simple, and have no issues using it a lot. Now, there are some readability discussion to using var, but that is purely subjective.

Everything Happens at Compile-Time

The very important concept that has to be understood is that with var, everything happens at compile time. You make the compiler work a little more when building your assembly, but the generated IL is exactly the same than if you explicitly use types.

So, the performances are only at compile time, and frankly, who cares of the performances at compile time?

Let’s go over this again.

Look at this code and the generated IL:

static void Main(string[] args)
{
    var s = "Hello";
}
.method private hidebysig static void Main(string[] args) cil managed
{
    .entrypoint
    .maxstack 1
    .locals init (
        [0] string s)
    L_0000: nop
    L_0001: ldstr "Hello"
    L_0006: stloc.0
    L_0007: ret
}

Now the same code, using var instead of String:

static void Main(string[] args)
{
    var s = "Hello";
}
.method private hidebysig static void Main(string[] args) cil managed
{
    .entrypoint
    .maxstack 1
    .locals init (
        [0] string s)
    L_0000: nop
    L_0001: ldstr "Hello"
    L_0006: stloc.0
    L_0007: ret
}

Exactly the same IL. Exactly.

To quote MSDN:

It is important to understand that the var keyword does not mean "variant" and does not indicate that the variable is loosely typed, or late-bound. It just means that the compiler determines and assigns the most appropriate type.

It cannot be more clear!

So please, stop picking on the poor var. Go pick on dynamic.

October 29, 2010 | Tags: , , | Leave a Comment 

Parameter Passing and Reference Types in C#

A few days ago, I had a question at work on why “regular” objects could be modified when in a method, while strings couldn’t. That’s a good question that any C#/Java developer (and many other languages) will ask at some point.

The issue there is the general misunderstanding about parameter passing in C#. My response to that is generally to say that “In C#, all parameters are passed by value”. Which is wrong if you include ref and out modifiers, but I won’t cover these in this post. I say it that way because it makes people think about it. Generally the first answer is “No because I can modify an object in a method!”.

That’s when you realize that most of the people understand the logic, but have issues being precise on telling what is truly happening. It has to do with the fact that strings are reference types in .NET. Taken from MSDN:

Variables of reference types, referred to as objects, store references to the actual data.

To get with my previous statement, the value of a reference variable is the reference to the actual data. Also, the actual data will be stored on the heap, but this is implementation details that we should not take into account.

So, to sum it up, when you pass a variable of reference type to a method, you actually pass the reference itself, as a value, to the method.

Here is very simple sample of code to illustrate all of that:

static void Main()
{
    String name = "Philippe";

    Console.WriteLine(name);

    Modify(name);

    Console.WriteLine(name);

    Console.ReadLine();
}

static void Modify(String text)
{
    Console.WriteLine(text);

    text = "Hello";

    Console.WriteLine(text);
}

And here is the printout for this:

Philippe

Philippe

Hello

Philippe

Let’s examine the memory during the different phases.

Here is the memory just before the call to Modify:

Memory1

Now, here is the memory when entering Modify:

Memory2

We can see that both text and name variables have the same value, namely the reference to a location in the heap that contains a string which content is “Philippe”.

Now, with that picture in mind, it’s very easy to imagine what will happen when we change the value of text:

Memory3

As simple as that. We modified the value of text, assigning it the reference to a string containing “Hello” somewhere in the heap. But we didn’t modify the name variable nor it’s content.

When we exit the Modify method, text variable gets out of scope and is eligible for garbage collection. The name variable was not modified in the process.

Now, this confusion also arises because of the fact that string are immutable. Mutable object’s internal content can be modified if you have a reference to them, but this does not hold true for immutable reference objects as you don’t modify them, you create new.

For a very good extensive tutorial on this topic, please see Jon Skeet’s excellent article on the subject. It’s probably much more clear that what I can explain.

October 18, 2010 | Tags: , | Leave a Comment 

← Previous Page — Next Page →