Frage

Nehmen wir an, wir haben eine etablierte Lösung in Visual Studio 2008, bei der WSPBuilder sie in ein Paket einbündet. Es verfügt über eine Handvoll Funktionen und eine ganze Menge Vermögenswerte für die Bereitstellung (.webPart, .xsl, .js, Bilder, Site -Spalten, Inhaltstypen usw.) sowohl für Bibliotheken für die Site -Sammlung als auch in den 12 -Hive -Bienenstock.

Was würden Sie vorschlagen, dass der Ansatz für das Jahr 2010 sein sollte?

Ich habe das seltsame Gefühl, dass SPI -Ordner (so schön wie für die Verwaltung von Modulelementen) in einer VS2010 -Lösung mit mehreren Funktionen im einen Projekt ziemlich beschäftigt und schwer zu verwalten sind. Würden Sie WSPBuilder noch verwenden und Ihre 14/Vorlage/Funktionen/ETC -Ordnerhierarchie im Projekt haben?

Außerdem mag ich die Designflächen "Lösung" und "Feature" -Design, insbesondere wenn Sie eine VS2010 -Lösung mit mehreren Projekten mit einer Handvoll Funktionen haben.

Hat noch jemand Erfahrung mit mittelgroßen und up-VS2010-Lösungen?

Außerdem: Die Annahme ist, dass die 2010 -Lösung auf der Farm eingesetzt wird.

War es hilfreich?

Lösung

WSPBuilder in CKs: Development Tools Editionerweiterung für VS2010.http://cksdev.codeplex.com/

Ps. Muss diese Erweiterung für die SP -Entwicklung haben.

Andere Tipps

Wir haben kürzlich eine Migration von 2007 bis 2010, mittelgroßes Projekt (Silverlight Webparts, 30 andere Webparts, WFC, Bilder, JS, Listendefinitionen, Feature -Empfänger und vieles mehr) durchgeführt. Wir haben alle Webparts in visuelle Webparts konvertiert (wir haben festgestellt, dass die Farmlösung in Ordnung ist), einschließlich Namespace -Konventionen. (Mussten jedoch Webparts auf Publishing -Seiten neu erstellen). Wir haben auch die SP -Kartenordnerfunktion von VS2010 verwendet, um Layouts und Bilderordner hinzuzufügen. Unser alter Code hatte hart codierte 12 Hive-Verzeichnisse, wir haben sie geändert, um 14 Hive über Appsetings zu verwenden. Außerdem haben wir uns entschlossen, alles in einer Funktion zu bündeln.

Ich verwende drei Erweiterungen - SP -Elektrowerkzeuge, Produktivitäts -Elektrowerkzeuge und Powercommands für VS2010. Ich benutze WSPBuilder nicht mehr, sondern verwende die integrierte Bereitstellungsfunktion von VS 2010. Ziemlich nützlich.

Mein Team hat ein großes SP2007 WSP Builder -Projekt in SharePoint 2010 konvertiert. Einige wichtige Dinge, die Sie sich erinnern sollten, insbesondere wenn Sie auch die SharePoint -Inhaltsdatenbank aktualisieren:

Wenn Sie Funktionen nachdenken, denken Sie daran, dieselben Funktionen -IDs zu verwenden.

Ändern Sie keine Montagenamen, Namespaces für Dinge wie Webparts und EventRecivers und andere Dinge, auf die in der Datenbank verwiesen wird.

Ändern Sie den Bereitstellungsort für SharePoint -Artefatcs nicht. Wenn Sie keine Funktionen für Funktionen schreiben möchten, die den neuen Speicherort der erforderlichen Dateien definieren, können Sie bei großem Projekt schmerzhaft sein.

Verwenden Sie beim Nachbau das richtige SharePoint -Projektelement. Wenn nicht, fehlt möglicherweise spezifische Funktionen bei Visual Studio für dieses Projektelement.

In den meisten Fällen funktioniert der folgende Workflow recht gut. Erstellen Sie ein neues WebPart -Element in VS2010 -> Ersetzen Sie IDs, Elementdateien und Code aus dem WSP 2007 -Projekt -> einige Optimierungen.

Mit CKS-dev und VS2010 ist die Entwicklungserfahrung großartig.

Ich habe eine Lösung mit mehr als einer Funktion und einigen Vermögenswerten migriert, die von 2007 bis 2010 im Layout -Ordner bereitgestellt wurden. Ich war mit dem Außenlebnis in Visual Studio 2010 zufrieden, nachdem ich mich daran gewöhnt hatte. Die Migration war etwas manueller als ich zunächst erwartet hatte, aber insgesamt nicht übermäßig komplex. Ich empfehle, die Migration mit den Out -of -the -Box -Tools zu beginnen, um mit ihnen die Vertrautheit aufzubauen. Dies könnte Ihre zukünftige Abhängigkeit von Tools von Drittanbietern verringern, die möglicherweise nicht gut aufgerüstet oder ebenso wie vollständige MS-unterstützte Tools aufrechterhalten werden.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit sharepoint.stackexchange
scroll top