Ich wurde gebeten, einige Benutzersteuerungen in ASP.NET zu entwickeln, die zu einem späteren Zeitpunkt auf einer SharePoint-Website als Webparts abgerufen werden. Ich bin neu in SharePoint und habe keinen Zugriff auf einen SharePoint-Server während der Zeit, die ich für die Prototypen dieser Teile benötige.
Kennt jemand irgendwelche Gründe, dass dieser Ansatz nicht funktioniert? Wenn dieser Ansatz nicht empfohlen wird, was wären andere Optionen? Irgendwelche Vorschläge zu einer Ressource / Anleitung, was bei der Entwicklung eines ASP.NET-Webparts mit SharePoint zu beachten ist?
Danke
Bearbeitung: 31.12.2008 Endlich habe ich eine Antwort darauf gefunden. Es hat eine Weile gedauert, bis ich festgestellt habe, dass es die beste Möglichkeit ist, die SharePoint-Route sofort zu nutzen, auch wenn sie zunächst schmerzhaft ist. Das freie VPC-Bild macht den Aufbau relativ schmerzfrei.
Während Sie, wie ich, Webparts in ASP.NET ohne SharePoint entwickeln können, haben Sie bei der Entwicklung und Bereitstellung von SharePoint-Anwendungen nichts gelernt, sondern nur die Lernkurve in eine Zeit verschoben, in der Sie denken Sie sind fertig (und haben die Interessengruppen wahrscheinlich diesbezüglich informiert). Um die SharePoint-Lernkurve zu verzögern, tun Sie oder Ihr Projekt keinen Gefallen, und Ihr Endprodukt ist besser für das Fachwissen, das Sie auf diesem Weg gewinnen.
Wenn es sich um eine sehr kurzfristige Sache handelt, hat Microsoft ein zeitlich begrenztes WSS-Evaluierungs-VPC-Bild:
WSS3 SP1 Developer Evaluation VPC-Bild
Damit können Sie beginnen, wenn Sie gerade keine Zeit / Ressourcen haben, um Ihr eigenes VPC-Image einzurichten.
ASP.NET-Webparts funktionieren in SharePoint genauso wie sie in ASP.NET funktionieren. Das ist die Route, die ich nehmen würde (benutzerdefiniertes Steuerelement, das von der Klasse ASP.NET-Webpart abgeleitet wird) . Dies verringert die Notwendigkeit, sich tatsächlich auf einem SharePoint-Server zu entwickeln.
Das einzige Problem, auf das Sie stoßen werden, ist, dass Sie das SharePoint-Framework nicht nutzen können. Wenn Sie etwas in SharePoint fortgeschritten sind, ist dies eine große Sache. Allerdings ist SharePoint ASP.NET plus einige zusätzliche Funktionen, also alles, was Sie mit dem System.Web.UI.WebControls.WebPart Klasse sollte in SharePoint gut funktionieren.
Einige Überlegungen, die Ihnen helfen werden, Ihre Probleme zu verringern, wenn Sie von reinem ASP.NET zu SharePoint wechseln:
Hier ist ein relevanter Blogpost; Einfache Webparts in SharePoint 2007 entwickeln
Ich denke, der einfachste Weg ist die Verwendung des SmartParts für SharePoint von CodePlex. Die Projektbeschreibung lautet: "Der SharePoint-Webpart, der jedes ASP.NET-Webbenutzer-Steuerelement hosten kann . Erstellen Sie Ihre Webparts, ohne Code zu schreiben!", Was genau das ist, was Sie tun möchten.
Erstellen und testen Sie das Steuerelement wie für eine typische .net-Website. Lösung 1 = die Kontrollen Lösung 2 = Dummy-Website zum Hosten der Steuerelemente.
Bereitstellung auf Sharepoint:
Sie müssen die Steuerelemente signieren.
Legen Sie die signierte DLL in den GAC auf dem Sharepoint-Server (Windows / Assembly)
abMarkieren Sie das Steuerelement als sicher im Stammverzeichnis web.config des virtuellen Servers auf der Sharepoint-Site.
d. h.
%Vor%Registrieren Sie die Komponente auf Ihrer Sharepoint-Seite:
%Vor%Verwenden Sie das Steuerelement:
%Vor%Wenn Sie das Steuerelement mit derselben Versionsnummer ersetzen müssen, müssen Sie den App-Pool neu laden, um ihn erneut zu laden.
Wenn Sie keine SharePoint-spezifischen Aufgaben ausführen müssen (z. B. Zugriff auf Listen, andere Webparts usw.), können Sie Ihr Webpart wie ein normales Webpart (abgeleitet von System.Web.UI.WebControls.WebParts.WebPart) erstellen Klasse) und es funktioniert, wenn es zu einer SharePoint-Website hinzugefügt wird.
Sie müssen Zugriff auf einen Sharepoint-Server haben, da Sie Ihren Webpart nicht ohne ihn simulieren können. Sie müssen ihn auf Ihrer Sharepoint-Site bereitstellen, um zu testen, ob er funktioniert. Debugging wäre auch ein Schmerz. oder Sie können SmartPart verwenden, es ist ein Webpart, der wie ein Wrapper für Ihre Benutzersteuerelemente in einer Sharepoint-Site angezeigt wird.
Sie benötigen SharePoint nicht, um WebParts zu entwickeln. Sie können Webparts entwickeln, indem Sie von System.Web.UI.WebControls.WebParts erben. Und dies ist die bevorzugte Methode zum Erstellen von Webparts, es sei denn, Sie möchten die folgenden Funktionen wie
%Vor%In diesem Fall müssen Sie Webparts entwickeln, indem Sie von Microsoft.SharePoint.WebPartpages.WebPart erben. Weitere nützliche Informationen finden Sie hier
Gibt es einen bestimmten Grund, warum Ihre Benutzersteuerelemente als Webparts bereitgestellt werden müssen? Es ist durchaus möglich, Benutzersteuerelemente direkt auf Sharepoint-Sites entweder über den Ordner CONTROLTEMPLATES in der 12-Struktur oder über einen Speicherort im virtuellen Webanwendung-Verzeichnis bereitzustellen, auf den Sie dann mithilfe von SharePoint Designer von Webseiten verweisen können.
Wenn jedoch die Webpart-Anforderung entscheidend ist, empfehle ich Smartpart for Sharepoint wie bereits erwähnt.
Tatsächlich sollten Webparts aufgrund ihrer "missbräuchlichen" Art immer im Ordner bin des Sharepots bereitgestellt werden. Wenn möglich, stellen Sie Webparts nach Möglichkeit in den Bin und schreiben Sie Ihr eigenes CAS und fügen Sie es in Ihr Manifest ein.
Tags und Links sharepoint web-parts