I found this to be a total pain to figure out how to fix, but once done, the solution is actually very simple.

My setup:

Most people doing Sharepoint development will be doing so in a proper networked environment (setup by a proper network admin). In which case this article is unlikely to apply to you and this article, can probably point you in the right direction (hint: you need to set your web.config proxy settings).

I am running a Sharepoint development environment at my house, using VMWare, with a minimal win2k3 setup. I’m not a server admin and I’m conscious hits to performance so the environment is very lightweight. No Domain Controller, no Active Directory. I’m a developer not a sysadmin.

The problem:

Unfortunately, Sharepoint cares not for my developing ways and when I tried adding an RSS webpart to a Sharepoint page got the following on-screen error:

An unexpected error occured processing your request. Check the logs for details and correct the problem.

Crapola. First I thought dodgy rss.

Nope.

Then I thought, the IIS account doesn’t have web access.

Nope.

So then I looked at the million and one “Sharepoint rss proxy” articles on Google to no avail. They all want you to make changes to the defaultProxy entry in your Sharepoint’s web.config.

Nope.

The cause:

For some reason, if you don’t have a proxy setup, Sharepoint throws it’s toys out the pram and won’t work. It won’t even try to make a network call (I checked using WireShark). Even when I tried to tell the defaultProxy entry to bypass all addresses, it ignored me.

I then followed the instructions on support.microsoft.com as best I could under the “Installing the Routing and Remote Access Service” heading.

Then magically my rss webparts worked

Also important is to make sure you use a proper RSSViewer part instead of a RSSAggregatorWebPart (added manually). The only difference I can see is in the configuration xml, but the latter continued to break even after my changes.

There are a number of circumstances where you might want a web part to display differently depending upon the display mode of the page.

For example:

you might want to provide detailed instructions to the user while in edit mode (or connections mode, etc.);

the scriptaculous & prototype libraries conflict with Sharepoint javascript while in edit mode, causing a range of javascript errors;

you might want to provide a more rich user interface than Editor parts allow.

To do so, is quite simple in concept, just identify the display mode, and chuck an “if” statement in there. However, it did take me a while to find the right code and I thought it was worth posting about, especially because it can help you give users a more professional & polished interface.

First, where I looked for the display mode. There’s a WebPartManager class which exists, and has a display mode, but it’s tricky to find an instance.

If while inside CreateChildControls or OnPreRender you try:

WebPartDisplayMode currentMode = this.WebPartManager.DisplayMode;

you will get a null pointer exception, because this.WebPartManager == null. I don’t understand why, but it does.

What you need to do is execute the static GetCurrentWebPartManager function on your current page object (found this from a post by Rich from DevAndDesign.com).WebPartManager wpm = WebPartManager.GetCurrentWebPartManager(this.Page);

This relies on the boolean AllowPageDesign property. If true, the page is in edit mode (that includes the edit, connect, design & catalog modes). It’s definitely a bit silly that this.WebPartManager doesn’t work, especially because it’s such a simple property to implement. Maybe somebody can fill me in on the history?