Installing SP2007 solution to SP2010

It went actually pretty smoothly, however I met one error in our solution:

The path to the configuration data of the solution was done in following way:

Environment.GetFolderPath(Environment.SpecialFolder.CommonProgramFiles) + @"\Microsoft Shared\web server extensions\12\Config\oursuperconfig.xml");

The “12” folder is hard coded into the string so it cannot work for sp2010 because it stores data in the “14” folder.

I found a SharePoint function SPUtility.GetGenericSetupPath that can handle this problem. This function returns the correct folder for both SP versions:

SPUtility.GetGenericSetupPath("config")+"oursuperconfig.xml"

Advertisements

SharePoint Solution Installer support for SP2010

I modified the SharePoint Solution Installer and now it supports SharePoint 2010.

I added following config entry into the setup.exe.config

<add key=”SupportedSharePointVersion” value=”2007″/>
If it contains value “2007”  then the solution can be installed only to MOSS 2007 and WSS 3.0

If it contains “2010” the the solution can be installed only to SharePoint 2010 and SharePoint Foundation.

If you leave it empty then no check for specific version of SP is done and you can install it to all above versions.

You can download the modified SSI binaries and source code from here. (It is actually a zip file renamed to jpeg because of WordPress policy.)

Is AllowUnsafeUpdates=true the right way?

Have you ever seen the following message?

System.Exception: Microsoft.SharePoint.SPException: The security validation for this page is invalid. Click Back in your Web browser, refresh the page, and try your operation again. —> System.Runtime.InteropServices.COMException (0×8102006D): The security validation for this page is invalid. Click Back in your Web browser, refresh the page, and try your operation again.

Some programmers say immediately “You have to set AllowUnsafeUpdates on the Web to true and the error will be gone.” Some programmers will add: “And don’t forget to set it back to false when you’re done”.

However this brings some issues:

• This will enable SharePoint to modify the data even during POST request types. So it can happen, that e.g the search server,  will modify the your SPListItems, while crawling.
• Additionaly sometimes the AllowUnsafeUpdates is automatically set back to false, e.g. when calling a Parent web.

So how to deal with it?

If you want to enable the modifications only in GET request types (e.g. in OnClick handler), then use SPUtility.ValidateFromDigest(), before you want to modify the data in SharePoint.  This will automatically set AllowUnsafeUpdates to true if the request type is GET.

For more info see following cool posts:

What You Need To Know About AllowUnsafeUpdates

What You Need To Know About AllowUnsafeUpdates part 2