Migrazione una soluzione 2007-2010

Question

Diciamo che abbiamo una soluzione consolidata in Visual Studio 2008, utilizzando WSPBuilder per impacchettare in su in un pacchetto. Ha una manciata di funzioni e un intero whack dei beni da distribuire (.webpart, xsl, .js, immagini, colonne del sito, tipi di contenuto, ecc) per entrambe le librerie delle raccolte siti e il 12 alveare.

Che cosa suggerisce l'approccio dovrebbe essere per andare al 2010?

Ho una strana sensazione che le cartelle SPI (bella come lo sono per la gestione del modulo Elementi) stanno per diventare piuttosto affollato e difficile da gestire in una soluzione VS2010 con diverse caratteristiche nel progetto uno. Quindi, sarebbe ancora usare WSPBuilder, e avere il vostro / CARATTERISTICHE / gerarchia 14 / MODELLO etc cartella nel progetto?

Inoltre, mi piacciono le orrendamente e superfici di design "soluzione" "feature", in modo particolare quando si dispone di una soluzione VS2010 con diversi progetti, ognuno con una manciata di caratteristiche.

Chiunque altro ha esperienza con medie-e-ancora VS2010 soluzioni?

Anche:. Il presupposto è che la soluzione 2010 sarà distribuito alla Fattoria

Answer 1

WSPBuilder in CKS: strumenti di sviluppo Edition Extension per VS2010. http://cksdev.codeplex.com/

PS. Deve avere questa estensione per lo sviluppo SP.

Answer 2

Abbiamo fatto una recente migrazione 2007-2010, progetto di media grandezza (webparts Silverlight, 30 + altri WebParts, WFC, immagini, js, elenco defintions, ricevitori Feature e molto altro ancora). Abbiamo convertito tutti i webparts per WebParts visivi (abbiamo determinato Solution Farm è ok), comprese le convenzioni dello spazio dei nomi. (Dovuto webparts Ricrea nella pubblicazione di pagine però). Abbiamo usato anche la capacità SP Mappa cartella di VS2010 aggiungere layout, immagini le cartelle. Il nostro vecchio codice era hard-coded 12 HIVE directory, abbiamo cambiato loro di utilizzare 14 HIVE via appSettings. Inoltre abbiamo deciso di impacchettare tutto in una caratteristica.

Io uso tre estensioni - Strumenti SP di alimentazione, strumenti di produttività di potenza e PowerCommands per VS2010. Io non uso WSPBuilder più, ma utilizzare il built-in funzione di distribuzione di VS 2010. piuttosto utile.

Answer 3

La mia squadra ha convertito un progetto costruttore WSP grande SP2007 a SharePoint 2010. Un paio di cose importanti da ricordare, soprattutto se si sta aggiornando il database del contenuto di SharePoint così:

Quando caratteristiche che ricreano ricordarsi di utilizzare la stessa caratteristica id.

Non modificare il montaggio i nomi, gli spazi dei nomi per cose come webparts e EventReceivers e altre cose che si fa riferimento nel database.

Non modificare la posizione di distribuzione per artifatcs SharePoint. A meno che non si vuole scrivere una funzione di aggiornamento elementi che definiscono nuova posizione dei file richiesti, può essere doloroso se grande progetto.

Usa l'elemento di progetto SharePoint corretto quando si ricrea. In caso contrario, funzionalità specifiche potrebbe essere manca da Visual Studio per l'elemento del progetto.

Nella maggior parte dei casi, il seguente flusso di lavoro funziona abbastanza bene. Crea nuovo elemento webpart in VS2010 -> sostituire ids, file di elementi e il codice dal progetto WSP 2007 -.> Fare alcune modifiche

Con CKS-Dev e VS2010 l'esperienza di sviluppo è grande.

Answer 4

Ho migrato una soluzione con più di una caratteristica e alcuni asset distribuiti ai layout cartella dal 2007 al 2010. Sono stato felice con la dall'esperienza di dialogo in Visual Studio 2010 dopo che mi sono abituato. La migrazione è stata un po 'più di quanto mi aspettassi manuale in un primo momento, ma nel complesso, non eccessivamente complesso. Mi consiglia di iniziare la migrazione con l'Out of the Box strumenti per aiutare a costruire la familiarità con loro. Questo potrebbe ridurre la dipendenza futuro su strumenti di terze parti che non possono aggiornare bene o essere mantenuto così come strumenti di MS pieno supportati.

Answer 5

Consulta le nostre 4 serie parte su porting di una soluzione WSPBuilder SharePoint 2007 a SharePoint 2010 .