Comparing a Value Type with null does not box
Recently, I discovered something like this my current codebase:
var g = Guid.NewGuid(); if (g == null) throw new Exception("Exception");
Of course, there are other statements in between, this is just an over simplifications. The idea, however, is to compare a value type with null, which makes no sense if you know .NET a bit, but can be found all over the world I am sure.
Without checking, I was sure that this would result in boxing the value type, followed by a comparison of the reference of the box with null, which will always return false.
Well, it turns out that I was wrong. The compiler is smart enough and ignores the statement in this case, as it is useless.
Now, what if there is an else statement in there?
if (g == null) throw new Exception("Exception"); else Console.WriteLine("boxed?");
In this case, the compiler only emits that is in the else statement. It is once more smart enough.
Let’s push it a little bit. What happens if we do this:
var b = (g == null); if (b) Console.WriteLine("boxed?");
In this case, the compiler will emit all the instructions, although it’s obvious that Console.WriteLine will never be executed. But still, no boxing.
Once more, C#’s compiler is very smart about all this. There is no boxing happening in the three cases.
Dropping Internet Explorer 9
It’s not even been 30 days as I stated earlier, but I’m going to drop Internet Explorer 9 and go back to Google Chrome…
Why you may ask? Here is why:
- No built-in spell checker (there is an add-on, but I don’t want an add-on, I want it built-in and on the fly);
- It does not reopen the tabs that were opened when it was last closed. Annoying at best;
- It’s slow. It’s faster than IE 8, ok, but still, on my laptop, it’s sluggish in Twitter and other highly charged pages.
Needless to say, Chrome does not have any of these issues. By the way, IE9 does not run on XP, while Chrome does (and is bloody fast, still).
Sad but true, to me it’s another failed browser. It’s nice, it’s fast, but not fast enough. Once you are used to Chrome’s speed, there is no going back, every other browser feels slow.
Maybe in a year or two, with some updates?
Internet Explorer 9 RC
The RC of Internet Explorer 9 is out at the following address: http://windows.microsoft.com/ie9
For the moment, I’m exclusively using Chrome for browsing. I started using it when it first came out to give it a try, and it was so amazingly fast that returning to any other browser was painful. However, with this new version of IE, things have changed. IE9 is very fast. Also, the search function works like in Chrome, which is obviously a plus.
So, what I will do is try to use IE9 exclusively for 30 days and see what comes out of it. If I enjoy it enough, I might switch to it as my main browser, who knows?
For now, the two things I want from Chrome is offline mails for gmail (which might come with Gears that I’m installing right now) and a spell checker.
Copy a Field’s Value to another Field in SharePoint
If one of your field data type needs to be changed, you will run into issues when deploying the new version of your application, as SharePoint can’t translate from one data type to another. For example, if you change a field type from “Single Line of Text” to “Notes” in Fields.xml, everything will go wrong.
The clean way to do this is to create a new field, the one that will be used from now on, and copy the value of the old field to the new field, while applying a transformation if necessary.
For this, we wrote a generic method that will go trough the entire site and perform the changes on the specified fields.
public static void CopyFieldValues(SPSite site, String copyFromFieldInternalName, String copyToFieldInternalName, Func<Object, Object> transformation) { foreach (SPWeb web in site.AllWebs) { //Get all the ListItems in every list of the web that has the 2 fields var items = (from l in web.Lists.Cast<SPList>() where l.Fields.ContainsField(copyFromFieldInternalName) && l.Fields.ContainsField(copyToFieldInternalName) from i in l.Items.Cast<SPListItem>() select i).ToList(); //For each listitem in this web, migrate the content of the old one to the new one //To do this, we use the tranformation Func that was given as a parameter foreach (SPListItem item in items) { item[copyToFieldInternalName] = transformation(item[copyFromFieldInternalName]); //Do system update to avoid modifying the item's version item.SystemUpdate(false); } } }
So, now that we have a generic method to copy the content of a field into another, we can “specialize” it for various uses.
One example is migrating a Single Line of Text type field to a Note type field. It is very easy because there is no transformation needed:
public static void CopyFieldValuesFromSingleLineOfTextToNote(SPSite site, String copyFromFieldInternalName, String copyToFieldInternalName) { //No need to transform the data in this case SharePointFieldsHelper.CopyFieldValues(site, copyFromFieldInternalName, copyToFieldInternalName, oldFieldValue => oldFieldValue); }
More on IsSPBuiltInField…
Some follow up on my previous post…
I had to work with this a bit more today, so I wrapped it up a bit to make it more convenient to work with:
public static class SPFieldExtension { static IDictionary<Guid, bool> PublishingBuildInFields { get; set; } static SPFieldExtension() { Type type = typeof(FieldId); var propInfoArray = type.GetProperties(BindingFlags.Static | BindingFlags.Public); SPFieldExtension.PublishingBuildInFields = propInfoArray .Select(prop => (Guid) prop.GetValue(null, null)) .ToDictionary(g => g, g => true); } /// <summary> /// Check if the given field is a build in field of SharePoint (WSS and MOSS) /// </summary> /// <param name="guid"></param> public static bool IsSPBuiltInField(Guid guid) { return SPBuiltInFieldId.Contains(guid) || SPFieldExtension.PublishingBuildInFields.ContainsKey(guid); } /// <summary> /// Check if the given field is a build in field of SharePoint (WSS and MOSS) /// </summary> /// <param name="field"></param> public static bool IsSPBuiltInField(this SPField field) { return SPFieldExtension.IsSPBuiltInField(field.Id); } }
So, I created a static class to hold my two methods. One is the same a the one in the previous post, taking a Guid and returning a Boolean. The second one is an extension method for SPField that simply call the first method. It’s more continent to use it this way.
