Frage

Ich wurde gebeten, einige Benutzersteuerelemente in ASP.NET zu entwickeln, die zu einem späteren Zeitpunkt werden in eine Sharepoint-Website als Webparts gezogen werden. Ich bin neu in Sharepoint und wird nicht während der Zeit, die ich diese Teile bis zum Prototyp benötigen Zugriff auf einen Sharepoint-Server.

Kennt jemand irgendwelche Gründe, dass dieser Ansatz wird nicht funktionieren? Wenn dieser Ansatz nicht zu empfehlen ist, was wären andere Optionen? Irgendwelche Vorschläge für eine Ressource / tutorial auf, was zu beachten, wenn eine ASP.NET-Webpart mit Sharepoint im Auge zu entwickeln?

Danke

Edit: 12/31/2008 Ich markierte schließlich eine Antwort auf diese ein. Es dauerte eine Weile, zu erkennen, dass die Sharepoint-Route sofort, wenn auch schmerzhaft auf dem ersten geht, ist der beste Weg, um darüber zu gehen. Das freie VPC Bild macht immer eingerichtet, um relativ schmerzlos zu entwickeln.

Sie können zwar, wie ich, Webparts in ASP.NET ohne Sharepoint entwickeln, wenn es um die Entwicklung und Bereitstellung von Sharepoint-Anwendungen Sie nicht etwas gelernt haben, schob nur die Lernkurve in eine Zeit ab, wenn Sie denken, Sie fertig sind, (und wahrscheinlich Beteiligten in diesem Sinne informiert). Um die Sharepoint-Lernkurve verzögern wird Ihnen oder Ihrem Projekt keinen Gefallen nicht tun, und Ihr Endprodukt wird besser für die Kompetenz, die Sie auf dem Weg zu gewinnen.

War es hilfreich?

Lösung

Wenn es sich um eine sehr kurzfristige Sache, Microsoft hat eine zeitlich begrenzte WSS Auswertung VPC Bild:

WSS3 SP1 Entwickler Auswertung VPC Bild

Das wird Ihnen den Einstieg, wenn Sie Ihre eigene VPC Bild keine Zeit / Ressourcen haben jetzt einzurichten.

Andere Tipps

ASP.NET Webparts arbeitet in Sharepoint die gleichen, wie sie in ASP.NET arbeiten. Das ist der Weg, den ich nehmen würde (individuelle Steuerung, die von dem ASP.NET Web Part leitet Klasse). Dadurch wird jede Anforderung lindern, um tatsächlich auf einem Sharepoint-Server zu entwickeln.

Das einzige Problem, das Sie stoßen werden, ist, dass Sie nicht in der Lage sein werden, die Vorteile des Sharepoint-Rahmen zu übernehmen. Wenn Sie etwas in Sharepoint voran tun, ist dies eine große Sache. Allerdings ist Sharepoint ASP.NET sowie einige zusätzliche Funktionen, so etwas können Sie entwickeln, um die System.Web.UI.WebControls.WebPart Klasse sollte in Sharepoint große arbeiten.

Einige Überlegungen, die Ihre Schmerzen lindern helfen, wie Sie von der reinen ASP.NET auf Sharepoint gehen:

  • Wenn Sie alles in einer einzigen Baugruppe setzen können, wird Bereitstellung einfacher
    • versuchen, alles, was Sie in die DLL müssen zu setzen, die auf Sharepoint
    • bereitgestellt werden
    • Verwendung Montage Ressourcen JS, CSS einzubetten und Bilddateien bei Bedarf
  • Strong Name der Baugruppe Sie bauen
    • Die meisten Sharepoint-Implementierungen Ende im GAC und ein starker Name erforderlich

Hier ist eine relevante Blog-Post; Grund Entwicklung Webparts in Sharepoint 2007

Ich denke, der einfachste Weg, um den Smartpart für Sharepoint von CodePlex zu verwenden ist. Die Projektbeschreibung sagt: „Die Sharepoint-Webpart die jede ASP.NET Web-Benutzersteuer hosten kann . Erstellen Sie Ihren Web-Teile ohne Code zu schreiben!“, Was ich denke, ist genau das, was Sie tun möchten.

meine Maschine einrichten entwickeln für Sharepoint hat mir ein paar Tage.

Siehe http: //weblogs.asp.net/erobillard/archive/2007/02/23/build-a-sharepoint-development-machine.aspx

Erstellen und testen Sie die Kontrolle, wie Sie es für eine typische .net Web-Site. Lösung 1 = die Kontrollen Lösung 2 = Dummy-Website, um die Kontrollen zu hosten.

Deployment auf Sharepoint:

Sie müssen, um die Kontrollen zu unterzeichnen.

Lassen Sie die signierte DLL in den GAC auf dem Sharepoint-Server (Windows / Montage)

Markieren Sie die Steuerung wie in der virtuellen Server root web.config auf der Sharepoint-Website sicher.

d.

<SafeControl Assembly="MyControl, Version=1.0.0.0, Culture=neutral, PublicKeyToken=975cc42deafbee31" Namespace="MyNamespace" TypeName="*" Safe="True" AllowRemoteDesigner="True" />

Registrieren Sie die Komponente in der Sharepoint-Seite:

<%@ Register Namespace="MyNamespace" Assembly="MyControl, Version=1.0.0.0, Culture=Neutral, PublicKeyToken=975cc42deafbee31" TagPrefix="XXXX" %>

Mit der Steuerung:

<XXXX:ClassName runat="server" Field1="Value1" Field2="Value2" ....></XXXX:Classname>

Wenn Sie die Steuerung mit der gleichen Versionsnummer ersetzen müssen, dann müssen Sie den App-Pool recyceln neu zu laden.

Wenn Sie nicht alles, was Sharepoint-spezifische tun müssen (dh Listen, andere webparts Zugriff, usw.), dann können Sie Ihre webpart bauen wie eine normale webpart (abgeleitet von System.Web.UI.WebControls.WebParts.WebPart Klasse) und es wird funktionieren, wenn auf eine Sharepoint-Website hinzugefügt.

Sie benötigen Zugriff auf einen Sharepoint Server haben, weil Sie nicht Ihre webpart ohne es zu simulieren, müssen Sie es auf Ihrer Sharepoint-Website bereitstellen zu testen, ob es funktioniert. Debuggen wäre auch ein Schmerz sein. oder Sie können Smartpart verwenden, es ist ein webpart, der wie ein Wrapper für Ihre Benutzer fungiert steuert in einer Sharepoint-Website angezeigt werden soll.

Sie müssen keine Sharepoint WebParts zu entwickeln. Sie können webparts entwickeln, indem sie von den System.Web.UI.WebControls.WebParts vererben. Und dies ist die bevorzugte Art und Weise Web-Teile zu schaffen, wenn Sie die folgenden Funktionen wie

wollen
* Connections between web parts that are outside of a Web Part zone

* Cross page connections

* A data caching infrastructure that allows caching to the content database

* Client-side connections (Web Part Page Services Component)

In diesem Fall müssen Sie webparts entwickeln, indem sie von Microsoft.SharePoint.WebPartPages.WebPart vererben. Sie können weitere nützliche Informationen finden hier

Gibt es einen besonderen Grund, warum Ihre Benutzersteuerungen müssen Webparts eingesetzt werden? Es ist durchaus möglich Bedienelemente direkt auf Sharepoint-Websites entweder über den Control Ordner in der Struktur 12 oder an einer Stelle in der Web-App virtuelle Verzeichnis zu implementieren, die Sie dann von Web-Seiten mit Sharepoint Designer verweisen können.

Wenn jedoch die Webpart Anforderung von entscheidender Bedeutung ist, dann empfehle ich Smartpart für Sharepoint, wie bereits erwähnt wurde.

Eigentlich sollte Webparts immer in den Ordner Bin Sharepoint bereitgestellt werden aufgrund ihrer ‚missbräuchlich‘ Natur. Immer Webparts in den Papierkorb, wenn möglich einsetzen und Ihre eigene CAS schreiben und es in Ihrem Manifest.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top