Ben There, Done That

If you’re like us, chances are you have users accessing SharePoint from several different browsers.  SharePoint 2007 can bring about many challenges for users not wanting to Internet Explorer, one of which is replying to threads in a SharePoint Discussion board.

To be perfectly honest I’ve never been a huge fan of the discussion board in SharePoint, so I haven’t often paid much attention to it.  However, since switching jobs, I have found the users here love the discussion board.  The first thing I did to make it even better for users, was to download the Quest Discussion board web part, to give users a much nicer interface for viewing posts.

Recently, more and more of our users have been accessing discussion boards from a browser other than IE.  When replying to a discussion, this brings up and ugly mess of HTML for the end users if they are replying from FireFox, Safari or Chrome.

We had three options for solving this:

1. Training – Make sure all users know that when replying to a discussion, they are not to touch the HTML, but simply add their response above it.  Feasible…but definitely not the best idea.

2. Require all users to use IE – hahaha…yeah right! Parts of our environment are accessible to our users from home as well as a subset of our users having the ability to choose if they want a MAC or a PC.  This just won’t happen.

3. Find a way for users to edit rich test (eliminating the HTML) when responding to or posting a new item in a discussion board.

Thanks to Telerik, we were able to take approach #3.  The Telerik RadEditor Lite (bottom of the page) provides two features.  One feature to use the RadEditor for Rich Text fields when using a browser other than IE and the second feature to use the RAdEditor for IE as well.  After adding and deploying the solution to the SharePoint farm and activating the feature on your SharePoint site, when you edit a Rich Text field from a browser other than IE, instead of the ugly html you are given a nice, easy to use Rich Text field from Telerik.

This is starting to get dangerous…I’m blogging about SharePoint development twice in a row.  Again, this may be something very basic to most SharePoint developers, but as I learn, I enjoy blogging about issues I’ve discovered and things I’ve learned as I continue to develop more.

My next venture into SharePoint development is to create some custom .ASPX forms for use within our SharePoint environment.  For our situation, InfoPath Forms Services would make much more sense, unfortunately, we only have SharePoint 2007 Standard with no plans to go to Enterprise.

So, I created a very basic .ASPX file with an equally as simple .cs (code behind file), packaged it all up as solution and deployed it.  However, when I went to access the site, I encounter a “Could Not Load Type…” error.  After a quick search on Google, I found – http://blogs.catapultsystems.com/matthew/archive/2007/12/07/could-not-load-type-error.aspx between that post and the post by Andrew Connell that was referenced there I was able to solve my problem.

When I had created my .aspx file I had failed to use the “5 part name” to reference the assembly file.  I had put Inherits=”NewForm.NewForm” rather than Inherits=”NewForm.NewForm, NewForm, Version=1.0.0.0, Culture=neutral, PublicKeyToken=*********”

As soon as I changed my .aspx file to use the 5 part name and redeployed my solution everything worked perfectly!

We have been having an issue with our search indexing and crawling in one of our SharePoint farms.  The problem is that after an undetermined set of time, pretty much all search queries wind up returning several results that show nothing but an IE icon.  The result isn’t attached or any page or give any textual information.  Obviously best case would be to figure out what causes this error, but at this point in time we haven’t been able to find the problem.

However, what we have discovered is that simply resetting the search index and running a full crawl will solve the issue.

So…until we can solve the issues, I wrote a small SharePoint timer job that simply resets our search index right before a scheduled full crawl runs.  I used Andrew Connell’s post (http://www.andrewconnell.com/blog/articles/CreatingCustomSharePointTimerJobs.aspx) to develop the Timer Job, Solution and Feature and modified it and was able to find the following code on http://www.sharepointdev.net/sharepoint–development-programming/programmatically-reset-all-crawled-content-41959.shtml that I inserted into the timer job frame work in order to automatically reset our index on a regular schedule to minimize the risk of our search issue effecting the end users.

try
{
    SearchContext sc = SearchContext.GetContext(ServerContext.Default);
    sc.Reset(true);
}
catch (Exception ex)
{
    throw new InvalidOperationException("Unable to reset content index.", ex);
}

For some of you, this may not seem like much, but coming from the SharePoint Administration/Configuration side of SharePoint and having very little real development experience I was rather proud of myself.