Migrating data from SP2001 to MOSS2007 is fun - if you know what I mean. During migration we discovered that migration tool has some serious bugs. I wrote some code that fixes some problems after importing process. There I found a problem - I needed to update list items without getting new versions of them after updates. Usually we see samples like this in internet:
SPList list = web.Lists["myList"];
SPListItem item = list.Items[0];
item["myField"] = "my value";
item.Update();
list.Update();
This code works perfect for end-user scenarios. It creates automatically new version of list item as Update method is called. I needed no new versions and there fore this solution wasn't great help for me. I found list item's method SystemUpdate. The following code is same as the previous one but instead of Update it uses SystemUpdate.
SPList list = web.Lists["myList"];
SPListItem item = list.Items[0];
item["myField"] = "my value";
item.SystemUpdate(false);
list.Update();
SystemUpdate method avoids SharePoint 2007 to change modified date and modifier fields. Argument false tells that no new versions are expected. SystemUpdate solved my problem perfectly well.
I was listening one session on TechEd (night after long party, yeah) and I was thinking about automatic properties - are they really exact equivalent to usual properties? Something made me suspicious, so I opened my laptop at first free moment and checked out what's going on.
At first let's write a little class. We will use it later to play with automatic properties.
public class AutoPropTest
{
private string name;
public string Name
{
get { return name; }
set { name = value; }
}
public string Name2 { get; set; }
}
This class has one usual property (Name) and one automatic property (Name2). Now let's compile this class and let's see how this class looks in Reflector after compiling.
public class AutoPropTest
{ // Fields [CompilerGenerated
] private string <name2>k__BackingField;
private string name;
// Methods
public AutoPropTest();
// Properties
public string Name { get; set; }
public string Name2 {
[CompilerGenerated] get;
[CompilerGenerated] set;
}
}
Looking at the code we can see that usual property and automatic property are not synonyms of each other. Automatic property has unaccessible attribute to hold value. Also we can see there CompilerGeneratedAttribute that usual properties doesn't have.
To be honest, automatically generated attribute is not unaccessbile - you can access it using reflection. Although I see no point why someone should access this attribute directly.
Windows Installer is one of my favorite problem childs - of course, when it has mysteriuos problems. I found a problem when installing Outlook add-in on machine that has no extensibility features installed on it. Something was missing and installer gave me the famous "Unable to get installer types" error. After pointless waste of time tracing installer and checking its logs I checked out what's going on in file system.
By default, Extensibility.dll was not installed. When I added it to setup package manually it was copied to application folder as expected. But still nothing happened. I was even able to create some packages that installed without errors but add-in was not installed. Cool, ah?
Solution to this problem is simple. There is another version of Extensibility.dll that you can distribute and that is installed correctly without any problems.
Seems like there are some legal issues with Extensibility.dll that is referenced by default.
After creating add-in project using Visual Studio you have to delete reference to Extensibility.dll. Path to correct version of Extensibility.dll is as follows:
C:\Program Files\Common Files\Microsoft Shared\MsEnv\PublicAssemblies\Extensibility.dll
After adding correct reference, make sure you let Visual Studio to get the local copy of Extensibility.dll. You can see example on the image. Before deploying your setup package you must test it on "clean" machine that has no Extensibility.dll in Global Assembly Cache.
If your setup works okay on clean machine and also your add-in works when you open Outlook to test it then everything should be okay what matters Extensibility.dll.