"Dieser Webpart kann nicht angezeigt werden. Öffnen Sie diese Webseite in einem Windows SharePoint Services-kompatiblen HTML-Editor, wie beispielsweise Microsoft Office SharePoint Designer, um dieses Problem zu behandeln. Falls das Problem weiterhin besteht, wenden Sie sich an Ihren Webserveradministrator."

Dies ist mit großem Abstand meine Sharepoint Lieblingsfehlermeldung. Dahinter kann sich so ziemlich alles verbergen. Kürzlich erhielt ich diese Meldung, nachdem ich einige Änderungen an einem Dataview Webpart (DVWP) bei einem meiner Kunden vorgenommen hatte.

Typischerweise kommt diese Meldung, wenn man ein DVWP in einer Sharepoint Umgebung exportiert und in eine andere Importiert. Ursache ist in solchen Fällen die fehlerhafte Liste GUID, die innerhalb der XSL Transformation sowie als Parameter in den Webpart Eigenschaften gespeichert wurde.

In meinem Fall konnte ich diese Ursache allerdings ausschließen. Interessanterweise wurde der Fehler nämlich nur anonymen Nutzern der Seite angezeigt. Als angemeldeter Nutzer (mit Admin-Rechten) wurde der Webpart fehlerfrei angezeigt.

Nach einer Stunde relativer Ratlosigkeit und sprichwörtlicher Suche der Nadel im Heuhaufen fand ich glücklicherweise die Quelle des Fehlers.

Während der Entwicklung hatte ich die XSL Transformation des Wepart nicht direkt innerhalb des Webparts gespeichert. Stattdessen hatte ich sie in die Style Library ausgelagert. Was ich allerdings vergessen hatte: Die XSL Datei war zwar wunderbar ausgelagert, jedoch nicht veröffentlicht. Somit hatte ich als authentifizierter Benutzer zwar keine Probleme den Webpart anzuzeigen, anonyme Anwender konnten das Herzstück des Webparts - nämlich die Transformation - jedoch nicht zugreifen und erhielten somit (zurecht) die oben genannte Fehlermeldung.

        protected bool IsDesignMode()
        {
            bool designMode = true;
            if (this.Page != null)
            {
                WebPartManager wp = WebPartManager.GetCurrentWebPartManager(this.Page);
                if (wp != null)
                {
                    designMode = (wp.DisplayMode != WebPartManager.BrowseDisplayMode);
                }
            }
            return designMode;
        }

Kürzlich versuchte ich via stsadm -o restore das Sharepoint Backup eines Kundens auf meinem Entwicklungsrechner einzuspielen. Obwohl die Wiederherstellung problemlos lief, kam beim anschließenden Aufrufen der Seite stets nur die statische Meldung: HTTP 500, interner Serverfehler. Sowohl das Eventlog, als auch die Sharepoint-Log Dateien gaben keinen Aufschluss zur Ursache des Fehlers. Auch Google und Co waren wenig hilfreich.

Nach stundenlangem Probieren konnte ich die Ursache glücklicherweise doch finden: Sowohl der Kunde, als auch ich hatten einen englischen MOSS auf einem englischen Windows 2003 Server installiert. Im Gegensatz zu mir hatte der Kunde jedoch zusätzlich die deutschen Sprachpakete für MOSS und WSS 3.0 inkl. aktuellem Servicepack installiert.

Mein Fazit der Geschichte:

In Zukunft werde ich beim Aufsetzen einer Sharepoint Entwicklungsmaschine sofort die Language Packs installieren.

Möchte man als Entwickler einen Einstieg in die Entwicklung mit den Microsoft Windows Sharepoint Services (WSS) 3.0 oder den Microsoft Office Sharepoint Server (MOSS) 2007 finden, steht man zu Beginn vor einer eher ungewöhnlichen Frage:

"Welche Systemumgebung brauche ich, um überhaupt los legen zu können?"

Reicht für andere Einsatzzwecke normalerweise ein Windows Client Betriebssystem inklusive Visual Studio nebst dem ein oder anderen Tool aus, muss es für die Sharepoint Entwicklung ein vollständiges Server Betriebssystem sein.

Da die wenigsten Entwickler wohl einen Server als "Hauptbetriebssystem" nutzen, liegt der Griff zur einer Virtuellen Maschine nahe. Leider ist auch diese nicht ganz so einfach installiert. Zumindest nicht, wenn man nicht regelmäßig Windows Server installiert und konfiguriert.

Genau aus diesem Grund hat Tony Zink eine 20-Teilige Blog Serie veröffentlicht, die durch den Dschungel der Windows Server 2003 + SQL Server 2005 + Moss 2007 Installation und Konfiguration führt.

Ein deutsches Pendant in der Kombination Windows Server 2008, SQL Server 2008 und MOSS 2007 findet sich übrigens in Fabians Blog.

Was in beiden Beiträgen fehlt ist die Installation von Visual Studio. Dies sollte für uns als Entwickler jedoch kein Problem sein