Thursday, May 24, 2007

Microsoft SharePoint and WebPartTypeId

I've recently created some prototype web parts for Microsoft SharePoint 2003/2007/WSS 2.0/WSS 3.0 and one problem that occured was this: After a rebuild and redeploy of my web part library, none of the existing instances of my web parts on the pages did load anymore.

I figured out that this was because the WebPartTypeId (tp_WebPartTypeId) of the instances in the WebParts table had changed, but where did those ID:s come from and why did they change? Microsoft's schema documentation does not explain this as far as I can see, and I could not find those ID:s anywhere else in the database.

It turned out that the ID, which is stored as a GUID, seems to actually be an MD5 hash of the full name of the assembly and the full name of the type of the web part class. That's why my pages broke - I had changed the version number of the assembly, and the full name includes the version number.

Theoretically, you could get the details of how the WebPartTypeId is calculated by using the excellent .NET Reflector tool by Lutz Roeder, and investigating the WebPartTypeId property of the Microsoft.SharePoint.WebPartPages.WebPart class. Doing so would be naughty of course, unlike in the open source world where you are encouraged to pick things apart and see how they work.

If you know of any documentation that explains how (and more important why) WebPartTypeId is calculated, I'd love to hear about it.

Sunday, October 08, 2006

Long time no see

It's been a long while since I posted anything here. Just in case you were wondering, I'm busy with work and with some non-computer-related hobbies.

Sunday, June 05, 2005

nForce3 and USB1.1

I have a machine with nForce 3 chipset and an XDRUM XD-403 MP3 player (USB 1.1). These don't work very well together. In Windows XP, I could copy files to the player, but once I tried to upgrade the firmware of the player and that failed midway. Luckily the player has a firmware recovery mode. In GNU/Linux I couldn't get the player to mount even once, there was always some transfer errors that prevented that from working.

After a lot of Googling I found the probable cause and the solution - the nForce chipsets don't work well with USB 1.1 devices that don't follow the specs, but connecting an externally powered USB 2.0 hub between the computer and the player fixes the problem. And indeed, that worked in my case too. I bought a rather cheap D-Link USB 2.0 hub, and now everything works fine both in Windows and Linux.

References:
1. TCC370-based device fails with NForce based mainboard
2. Application Note nForce2 MCP-T/MCP USB 1.1 Device Compatibiity

Wednesday, February 23, 2005

The speed of ginstall vs install

Now and then I compile certain open source projects on Windows XP using Cygwin, and there is one thing that has annoyed me for a while. Every time the program /usr/bin/install is invoked, the explorer.exe Windows process, which is responsible for handling for example the Start menu and task bar, consumes 100% CPU for about a second. Since install is usually invoked many times, that unnecessarily slows down compilation.

Last week I got sufficiently annoyed to investigate what causes this. After some fruitless digging through Cygwin sources, I discovered that simply renaming install.exe to something else, like ginstall.exe, prevents the problem from happening. It turns out that executing any program named install.exe or setup.exe on Windows XP causes explorer.exe to consume CPU for a short while just when the program quits.

You can try this yourself, just copy a small program like c:\windows\system32\help.exe and name it install.exe. Open Task Manager, execute install.exe (preferrably from a command prompt), and watch explorer.exe briefly consume CPU. I have tested this on a few machines running Windows XP SP2.

What I guess explorer.exe is doing is to update the contents of the start menu, so that any newly installed software is immediately available, since software installation programs under Windows are normally named install or setup.

Sunday, February 13, 2005

libtool-cache

Tired of waiting for libtool when compiling software on Microsoft Windows and using Cygwin? Try libtool-cache, a tiny Open Source project I've created. Currently mostly meant for experienced developers.

Friday, January 28, 2005

Post 0x0001

Yay, first post!

Hopefully I'll have some interesting stuff to post now and then.