SharePoint Development Training

Good SharePoint training can be hard to find – and it can be expensive. Harder yet is convincing your boss that you need time off and travel expenses to go away for a week.

If you live in (or can get to) Houston in March, however, I may have some good news for you. One of my favorite SharePoint bloggers, Rafael Perez (http://blog.rafelo.com) is putting together one of his famous weekend crash courses in SharePoint Development.

This course provides an in-depth look at everything from basic Content Deployment to full Feature and Solution generation for Windows SharePoint Server and Microsoft Office SharePoint Server. The class is strictly “BYOL” – Bring Your Own Laptop, and runs two full weekend days long (March 21-22, 2009).

Best part is – you don’t go home empty handed. You get to keep a hard disk with trial versions of software loaded and the work you built in class, all for $500.

Not a bad deal, overall… Check it out here.

Changing the Scope of the Telerik RadEditor Features

Telerik provides the RadEditor for MOSS in a Solution package (*.wsp). This solution contains two Features, which are scoped to be installed at the Web level of a SharePoint farm.

While this type of installation is quite functional, it means that every time a Site (Web in the Object Model) or Site Collection (Site in the Object Model) is created, its administrator would need to remember to activate the solution.

The Telerik website specifies a workaround for this shows you how to modify the two Telerik Features (RadEditorFeatureRichHtml and RadEditorFeatureRichText) by doing the following:

1. Turning off the Features
2. Altering the Feature Scope for each in the Feature.xml file
3. Turning the Features back on

While this works fine, these steps did not meet my requirements - if the Solution that created the Features is reinstalled or modified, the feature.xml for each would be overwritten from the contents of the Solution. This would revert the scope back to Web instead of Site, which is not acceptable.

I specifically wanted to make this change more permanent such that it could survive the reinstallation of the solution (by the way, this works with the trial version of RadEditor). The only alternative was to modify the solution. To do so:

a. Make an archival copy of the original solution from Telerik. This document assumes that the copy is NOT named RadEditorMOSS.wsp.

b. Rename the RadEditorMOSS.wsp file to RadEditorMOSS.cab.

c. Open the RadEditorMOSS.cab file using WinZip (Not the built-in Windows Unzip). If you choose to use the builtin Windows Unzip, this process will not work because (a) the file structure will be gone and (b) the feature.xml for one of the two features will overwrite the other.

d. Choose to extract all files to a location of your choosing. For illustration’s sake, we will choose the location as C:\Downloads\Telerik\RadEditorMOSS_5_3_2\RadEditorMOSS.

e. Open the RadEditorMOSS directory and then open the RadEditorFeatureRichHtml directory. In it, you will see one Feature.xml file.

f. Open it in an editor of your choosing (VS2005/2008, Notepad++, etc.) - Don't use NotePad, it may leave artifacts and hidden characters in the file.

g. Find the Line that reads 'Scope="Web"' and change it to read 'Scope="Site"'.

h. Repeat steps e-g for the RadEditorFeatureRichText directory.

i. IMPORTANT - These files need to be reassembled back into a CAB file, but you cannot use WinZip for this task. If you do so, all will be well until you try and install the solution, at which time you will get an error that reads "Failed to extract the cab file in the solution".

j. Download and install the cabdsk.exe utility (to c:\Program Files\Cabdsk) from the Microsoft Cabinet Software Development Kit (see http://support.microsoft.com/kb/310618 and http://kopperla.blogspot.com/2008/10/how-to-replace-files-in-sharepoint.html).

k. Open a command prompt and navigate to the c:\Program Files\Cabdsk directory.

l. Issue the following command: cabarc n RadEditorMOSS.cab C:\Downloads\Telerik\RadEditorMOSS_5_3_2\RadEditorMOSS\*.*.

m. Issue the following command: cabarc -r -p -P downloads\telerik\RadEditorMOSS_5_3_2\RadEditorMOSS n RadEditorMOSS.wsp c:\downloads\telerik\RadEditorMOSS_5_3_2\RadEditorMOSS\*.*.

n. Copy the finished RadEditorMOSS.wsp file from c:\Program Files\Cabdsk to c:\download\telerik\RadEditorMOSS_5_3_2\.

o. Delete the C:\Downloads\Telerik\RadEditorMOSS_5_3_2\RadEditorMOSS directory that was created by unzipping the original file.

At this point, you can simply follow the instructions for activating the Solution and Features (at the Site Collection) as shown on the Telerik web site.

Getting AJAX 1.0-dependent items to function in an AJAX 3.5 environment

This last week I was tasked with installing the RadControls for ASP.NET AJAX from Telerik into a SharePoint environment. In particular, the desire was to integrate the fully functional version of RadEditor for SharePoint with a publishing environment.

I spent quite a bit of time reviewing the documentation for this product, and what I figured out pretty quick was that while the majority of this product runs under AJAX 3.5 (part of ASP.NET 3.5 Service Pack 1), the RadEditor control uses the legacy AJAX 1.0 functionality.

So, what to do next? I looked at the instructions for each and found that I could install both AJAX 1.0 and 3.5 on the same machine (although that really did not seem reasonable). Then I realized that both would require modification to the web.config for my SharePoint web app; the modifications would overlap, however, and I was pretty sure that this would not work.

Not being that familiar with AJAX, I did a little checking. AJAX 3.5 provides backward compatibility with AJAX 1.0 - so far so good. Next, the question was how to cause this to work in the web.config for my web application.

I started by adding the web.config modifications for ASP.NET 3.5 found in the Telerik installation instructions.

Next, I found out how to offer AJAX backward compatibility in a web.config from a post on the Telerik forums here. Basically, what this addition does is build a dependency entry that redirects AJAX controls to use the 3.5 AJAX. To set this up:

In the <runtime>/<assemblyBinding> section of the web.config, add the following entries:

<dependentAssembly>
  <assemblyIdentity name="System.Web.Extensions" publicKeyToken="31bf3856ad364e35" culture="neutral" />
  <bindingRedirect oldVersion="1.0.61025.0" newVersion="3.5.0.0" />
</dependentAssembly>

This last section should be all you need to allow the backward compatibility for any AJAX 1.0 functionality.

Pointers:

• Make backup copies of your web.config file before making any modifications.
• Make sure that if you are cutting and pasting this text in that no hidden characters are copied. Hidden characters will cause the web app not to function after the web application is reset.
• Don’t forget to reset the web application to allow these web.config modifications to take effect.