[Road to SharePoint 2010] Repackage Your Developments for a Better Tomorrow

Today I want to comment on what should you take care of when preparing your SharePoint 2007 customizations for the 2010 world.

The Good Guys

“The Good Guys” are those customizations that should behave well when upgraded.

Features

The existing SharePoint 2007 features will (hopefully) upgrade with no fuss. By looking on the disclosed SP2010 SDK, one can see that the features will be able to “upgrade” themselves, invoking SPFeature.Upgrade method. This call will run the code you specify in the upgrade feature UpgradeReceiverAssembly property. This will probably be a special feature that will upgrade the rest of the features in a given scope.

This code from the SDK illustrates the issue:

Furthermore, it seems that the features will be properly versioned (at least). Again, I quote the SDK:

The value of this property can be different from the value of the Version property of the underlying feature definition. For example, you might deploy a feature that uses a feature definition with a version number of 1. At that point, both the feature instance and the feature definition have the same version number. Suppose that subsequently you modify the feature definition and re-deploy it with a version number of 2. Now the feature definition is version 2, but the feature instance remains version 1. That indicates that the feature instance needs to be upgraded. You need to run feature upgrade code to move the version of the feature instance from 1 to 2.

Solutions (WSP packages)

This recommended way of packaging the features and enhancements will hopefully upgrade straight-forward. Even more, it seems that it will be possible to “sandbox” a solution to limit its visibility to just a single site collection, without affecting the rest of the farm. The SDK mentions a SPUserSolution class (“This class allows solutions to be uploaded at the site collection scope and run in a sandbox.”).

Site Definitions

According to the STSADM preupgrade check operation, custom site definitions will have to be upgraded in-place with a Upgrade Definition File (an XML file, for sure). Hopefully, it won’t be a nightmare. Watch for a not-yet-released KB article 954761 that should explain it.

image

The Bad Guys

“The Bad Guys” are those customizations that you will have to rewrite or repackage in order to make them upgradeable.

Custom CAML and Ad-hoc Views

There’s new guy in town for list views in SP2010: XSLT. This standard format will replace the mutant CAML when it comes to defining the view rendering the list items. However, it comes with a price. The preupgradecheck tool will warn you which of your custom views will not be upgraded. You could leave it in CAML and SharePoint 2010 will render it well, but you will lose the new features of the XSLT-based views such as conditional formatting or SharePoint Designer 2010 customization support.

The tools mentions that “A list view using custom Collaborative Application Markup Language (CAML), a list view not associated with a Feature, or a list view associated with a custom Feature, will not be upgraded to the new XSLT-based list view”.

Custom CAML-Rendered Fields

Another CAML to XSLT victim. The custom fields that use CAML in its RenderPattern will not be upgraded to XSLT fields.

Custom Workflow Action Types

A minor issue, this one. You will have to keep a copy of your web.config and manually restore your custom workflow activity types defined in <authorizedType> tags, as they will be replaced with the new type versions.

Site and List Templates (STP files)

If you are the happy end-user that saves lists and sites for reuse as STP template files, bad news. STP files won’t be supported in SP2010, as they were present in SharePoint 2007 only to provide you with backward-compatibility with SharePoint 2003. You will have to rewrite them as site or list definitions. You can use a tool like SharePoint Solution Generator (part of the WSS 3.0 SDK) to reverse-engineer an existing site or list into a definition and then fine-tune them by hand.

[Road to SharePoint 2010] Getting Ready for 64-bit World

Welcome to the second installment of the Road to SharePoint 2010 series. I will tackle the oldest news for this SharePoint version: it will be released only as a 64-bit installation. So, how do we prepare for this requirement? Well, by getting ready with our shiny new 64-bit servers and virtual machines.

image 
(check the original scan from a 1983 magazine here)

The hardware and software requirements were outlined on the official SharePoint team blog.

Which hardware it will need?

64-bit hardware has been recommended for SharePoint 2007 for some time. Testing data shows that SharePoint hugely benefit from improved memory management in 64-bit environment. SQL Server is also memory-intensive application, so it will be grateful for the extended memory space. Roughly, the database will benefit the most, following by the front-end web servers, and the application servers will benefit the least.

Which Windows it will need?

SharePoint 2010 will run on Windows Server 2008 / 2008 R2 x64.

Which SQL Server it will need?

SharePoint will need SQL Server 2005 or 2008 / 2008 R2 x64.

What for the developer Virtual Machines?

You are strongly recommended to have a 64-bit host OS for 64-bit virtual machines, although you still can run a 64-bit VM in a 32-bit host OS. If you are using 32-bit OS for the host, you must have a 64-bit capable processor (check here) and activate the 64-bit virtual extensions in the BIOS (called Intel VT or AMD-V, depending on the CPU maker).

You can use the Sun Virtual Box software or VMWare to create the virtual machine. Unfortunately, Virtual Microsoft PC cannot accept 64-bit client OS in the VM.

Do I have to worry about my custom .NET code in SharePoint? How can I port it to 64-bits?

You will have to recompile your source code in 64 bits configuration (or in AnyCPU build configuration). The 64-bit NET cannot load a 32-bit-only assembly.

If you don’t have the source code, as with IFilters or third-party extensions, you will have to obtain the 64-bit version, if available. If not, you will have to remove that component from the farm.

As for the NET Framework in 64 bits, there are useful references at MSDN to help us migrate our existing code. In short, if you stick to the managed code, you shouldn’t have problems. The problems arise when you use platform-dependent (alias P-Invoke) operations that cross the managed code boundaries and access the Windows directly. There’s a known issue with int data type pointers coming from COM or P-Invoke layer, you should use IntPtr data type instead.

If you want the gory details of the 32-to-64-bits issues, Scott Hanselman has a nice blog entry about it.

How to migrate my SharePoint farm from 32 to 64 bits?

The best way is to do it gradually.First you move the database tier, then the application servers and finally the web servers, as illustrated on this figure. Do not mix 32 and 64 bit servers on the same tier.

image

The recommended steps are outlined in this TechNet article:  http://technet.microsoft.com/en-us/library/dd622865.aspx

June Cumulative Updates for SharePoint Released

The WSS 3.0 June 2009 Cumulative Update über-package and MOSS 2007 June 2009 Cumulative Update individual packages are ready for download.

MOSS 2007:

972569 Global
http://support.microsoft.com/default.aspx?scid=kb;EN-US;972569

970948 Global
http://support.microsoft.com/default.aspx?scid=kb;EN-US;970948

970947 Language specific
http://support.microsoft.com/default.aspx?scid=kb;EN-US;970947

972562 Language specific
http://support.microsoft.com/default.aspx?scid=kb;EN-US;972562

972564 Forms Server Global
http://support.microsoft.com/default.aspx?scid=kb;EN-US;972564

WSS 3.0:

971538 uber package
http://support.microsoft.com/default.aspx?scid=kb;EN-US;971538

970946 Global
http://support.microsoft.com/default.aspx?scid=kb;EN-US;970946

The details of the patches are not yet fully available on Microsoft Support site.

The MOSS über-package is not yet ready due to dependencies with Project Server 2007.

(Source: Joerg Sinemus blog)

My First MOSS 2007 SP2 Upgrade

I’ve been trying to upgrade my development virtual machine to SharePoint 2007 SP2 today. No problems, except for the tiny detail….

The upgrade couldn’t find HOSTS file.

After some googling I’ve found the culprit: the MOSS Search. It changes some entries in hosts file but it deletes the file and recreates it. If your service account is not an administrator, bad news…the file can’t be created again.

More information on this bug by Jeremy Jameson: http://blogs.msdn.com/jjameson/archive/2007/05/05/the-case-of-the-disappearing-hosts-file.aspx 

After this minor glitch, now I can see that the version number is updated well:

image

Of course, I run the preupgrade check operation to see if my developer machine would be ported well to SharePoint 2010:

image

More explanation on preupgrade operation by Jie Li: http://blogs.msdn.com/opal/archive/2009/05/12/upgrade-checker-in-sp2-behind-the-scene.aspx

Windows Defender Update and the Page Error in Development Web Server

Another of the strange, unexplained errors with a simple (yet unexpected) cause.

SYMPTOMS

You are developing an ASP.NET Site or Web Project in Visual Studio 2005/2008. You start the Debug process. Your browser window opens with a message:

Page Load Error

or

The page cannot be found.

Additionally, you have Windows Defender installed on your machine.

THE CAUSE

A flawed update of the Windows Defender removes the localhost entries from hosts file in windowssystem32devicesetc folder.

SOLUTION

Manually add the following entries back to the hosts file:

127.0.0.1 localhost

More details: http://www.h-online.com/security/Windows-Defender-False-alarm-triggered-by-hosts-file–/news/112814

SharePoint 2007 Service Pack 2 Details Announced

There are official news about SharePoint 2007 and WSS 3.0 Service Pack 2 (SP2) from Microsoft TechNet. The new service pack will contain:

  • Improved Read-only Content Databases
  • Improved performance and manageability in variations, including STSADM commands for repairing links between source and target pages
  • Improved Index Rebuild Timer Jobs
  • SP2 Upgrade Checker

This SP2 will become available between February and April 2009.

SharePoint Infrastructure Updates

(a new buzzword to learn, together with “hotfix”, “patch”, “service pack” and “update”.)

Well, the thing is that the good folks at Microsoft have been working hard to fix the most annoying issues with SharePoint and to retrofit the new features they have developed. And the result is that we have two (actually more than two) infrastructure updates available for download:

Infrastructure Update for Microsoft Office Servers (KB951297)

This update adds Federated Search capabilities to MOSS search. It also adds a new streamlined “Search Administration” page. The next good news is that Content Deployment is finally largely rewritten and this fixed up a lot of intermittent errors.

image 

Infrastructure Update for Windows SharePoint Services 3.0 (KB951695)

This update mostly fixes workflow errors.

Download links

32 bits (x86)

64 bits (x64)

Office 2007 SP2 and SharePoint: ODF Friendly

Microsoft announced on May 21st that the new Service Pack for Office 2007 (SP2) will add native support for ODF and PDF files. Yes, that means opening and saving Open Document files (ODT for documents, ODS for spreadsheets, ODP for presentations), together with Microsoft-backed Open XML file format.

The official SharePoint blog quickly commented on the issue, too. Nice screenshot 😉

I think that this will mean, for SharePoint of course, a fully Microsoft-supported ODF and PDF IFilter, and maybe (although it’s a long shot) a DHTML viewer (à la Excel Services). Maybe not for the SharePoint 2007 SP2 but in time for SharePoint 2009. Who knows?

Windows Update KB932596 and VMWare Server on Vista x64

I was surprised to see that after a major Windows update process (the August 14th one) my VMWare Server stopped working. It began to give this error in the System Event Log:

The VMware Authorization Service service depends on the VMware vmx86 service which failed to start because of the following error:
Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.

I tried the usual trick (disabling driver integrity check) but it didn’t help.

The culprit is the Windows Security Update KB932596 (“Kernel Patch Protection Feature”). It reestablishes driver integrity check every time you reboot.

I uninstalled this update and rerun the trick. It is now working.