Sharepoint

HTTP Fehler 401 beim hinzufügen eines Custom WebParts

André Krämer — Sun, 21 Nov 2010 22:56:21 GMT

Gestern überraschte mich Sharepoint mit einem mir zunächst vollkommen unverständlichen Verhalten.

Ich versuchte zu einer Seite ein WebPart hinzuzufügen, welches ich kurz davor entwickelt hatte. Jedoch kam jedes Mal nachdem ich das Webpart auswählte ein Dialog der mich zur Eingabe von Benutzernamen und Passwort aufforderte. Meine korrekt eingegebenen Benutzerdaten akzeptierte der Dialog nicht. Der Klick auf “Abbrechen” führte schließlich zu einer Standard HTTP 401 Unauthorized Seite.

Weder im Event-Log, noch in den Sharepoint-Logs konnte ich Informationen zur Fehlerursache finden.

Also folgte einige Zeit der Ratlosigkeit und des Fluchens ehe ich mehr zufällig auf die Lösung kam:

Ursache des Problems war eine fehlerhaft von mir implementierte Property meines Webparts. Diese sah ungefähr wie folgt aus:

private string pfad
public string Pfad
{
   get
   {
      return Pfad.EndsWith("/")?Pfad:string.Concat(Pfad,"/");
   }
   set
   {
      pfad = value;
   }
}

Wie man sieht habe ich einen kleinen, aber entscheidenden Fehler innerhalb des Getters. Anstatt mein Feld mit dem Namen pfad zurück zu geben, gebe ich innerhalb des Getters der Eigenschaft Pfad die Eigenschaft Pfad zurück. Somit ruft diese Eigenschaft sich so lange selber auf, bis eine StackOverflowException auftritt.

Diese StackOverflowException führte dazu, dass der Workerprozess meiner Sharepoint Web Applikation recycled wurde. Somit waren meine zuvor eingegebenen Credentials ungültig und der IIS fragte mich erneut nach den korrekten Zugangsdaten.

Nachdem ich den Getter entsprechend korrigiert hatte, lies sich das Webpart problemlos einfügen.

private string pfad
public string Pfad
{
   get
   {
      return pfad.EndsWith("/")?pfad:string.Concat(pfad,"/");
   }
   set
   {
      pfad = value;
   }
}

Tags: .NET, Sharepoint, ASP.NET

Dieser Webpart kann nicht angezeigt werden

Andre — Mon, 16 Nov 2009 17:01:20 GMT

"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.

Prüfen, ob sich ein Webpart im Design Modus befindet

Andre — Thu, 17 Sep 2009 10:29:23 GMT

Während der Webpart Entwicklung kann es nützlich sein, zu wissen ob man sich gerade im Webpart Design Modus befindet. Folgender Codeausschnitt zeigt, wie man an diese Information kommt:

        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;
        }

Hilfreich ist dies zum Beispiel, um Validatoren während des Design Modus abzuschalten.

HTTP Error 500 nach Restore eines Sharepoint Backups

Andre — Mon, 18 May 2009 23:44:53 GMT

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.

Einstieg in die WSS 3.0 / MOSS 2007 Entwicklung - Die Systemumgebung

Andre — Wed, 05 Nov 2008 17:45:32 GMT

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 :-)