Devo mantenere le soluzioni e le caratteristiche di un rapporto di 1-1?

Question

Ho uno sharepoint complesso distribuire con più EventReceivers e flussi di lavoro.

Ho anche le modifiche allo schema di elenchi esistenti, l'aggiunta di nuove colonne di metadati e la modifica di colonne esistenti.

Devo pacchetto di una singola caratteristica, eventreceiver o del flusso di lavoro, ad un'unica soluzione, o dovrei mettere caratteristiche multiple all'interno della singola soluzione dal momento che tutto il lavoro insieme?

Uno dei motivi principali che chiedo è per gli aggiornamenti futuri di codice. Se le caratteristiche sono separati, quindi un upgrade in una porzione di codice non richiederebbe una re-implementazione di tutte le funzionalità nella soluzione. E 'questo qualcosa che dovrei preoccupare o fa il "StsAdmin -o upgradesolution" prendersi cura di eventuali problemi con l'aggiornamento di una soluzione con molte caratteristiche?

Vorrei sapere se questo ha un senso a qualsiasi guru SharePoint là fuori.

Grazie,
Keith

Aggiornamento: Guardando il sito Drax fa riferimento, ho trovato questo sito di riferimento: http://msdn.microsoft.com /en-us/library/aa543659.aspx

Questa affermazione sembra mettere un grande svantaggio per l'aggiornamento funzioni nelle soluzioni:

  

aggiornamento soluzione può essere utilizzata solo per   sostituire i file. È possibile aggiungere nuovi file   in una soluzione di aggiornare e rimuovere il vecchio   versioni dei file, ma non si può   Caratteristiche installare o utilizzare evento Caratteristica   i gestori per eseguire il codice per Caratteristica   installazione e attivazione. Il   seguenti operazioni non sono supportate   in soluzione di aggiornamento.

     

  

• La rimozione vecchie Caratteristiche in una nuova   versione di una soluzione.

  

• aggiunta di nuove funzionalità in una soluzione   l'aggiornamento.

  

• Aggiornamento o cambiando il ricevitore   montaggio per servizi già esistenti in un   nuova versione di una soluzione.

  

• elementi Feature aggiunta o la modifica   (file Element.xml) in una nuova versione   di una soluzione.

  

• L'aggiunta o la modifica Caratteristica   proprietà in una nuova versione di un   soluzione.

  

• La modifica della ID e la portata di vecchio   Caratteristiche in una nuova versione di un   soluzione.

  

• La rimozione elementi Feature   (file Element.xml) in una nuova versione   di una soluzione.

  

• La rimozione proprietà Feature in una nuova   versione di una soluzione.

  

Quindi ... Che cosa si può fare con una soluzione di aggiornamento?

Answer 1

Vorrei consigliare contro tutto frazionamento in più soluzioni. Mantenendo che può rapidamente diventare un incubo. Cercate di strutturare il progetto, che dovrebbe viene utilizzato per creare WSP, nel stesso modo in cui 12 cartella di SharePoint. Quindi è possibile utilizzare WSP costruttore , ultima versione stabile porta un sacco di cose utili.

Inoltre ho notato che non tutti i problemi con soluzioni ridistribuzione. Secondo questo articolo e alla mia esperienza di implementazione WSP si occupa di la sincronizzazione tra le versioni. Quindi, se si vuole aggiungere alcune nuove funzionalità appariranno e se si rimuove / funzioni di modifica saranno modificate di conseguenza.

A CURA:

Così ho fatto qualche ricerca veloce su MOSS argomento Aggiornamento. Secondo MS ci sono due modi di aggiornare le soluzioni:

1. In-luogo update
2. aggiornamento incrementale

In sostanza, sul posto aggiornamento è modo standard di aggiornamento. Significato si fa affidamento sulla funzionalità build-in come descritto in questo ( stesso documento pubblicato in precedenza) del documento. Problema con questa soluzione è che manca un sacco di funzionalità (versioning, la modifica di ID di di caratteristiche, ...).

aggiornamento incrementale (questo è il modo MS chiama probabilmente) non si basano su soluzioni build-in. Ciò significa che spetta a tutti di realizzare da soli :(. Che è anche meglio non ero davvero in grado di trovare delle linee guida per questo approccio. Suppongo che l'approccio si desidera prendere è esempio di aggiornamento incrementale (progetto dividendosi in molte soluzioni indipendenti).

Si noti inoltre che l'aggiornamento incrementale non è ufficialmente supportato da MS.

Quindi non so davvero che cosa consigli dovrei dare a voi. Singolo WSP è più maintanable di Buch di loro, anche se si sta facendo solo alcuni cambiamenti minori aggiornamenti funzionano perfettamente. Ma se è necessario apportare alcune modifiche strutturali più grandi problemi iniziano a mostrare.

Io probabilmente aspettare e vedere se le persone con più esperienza MOSS possono dire qualcosa su questo argomento.

Answer 2

In sostanza (per le ragioni che hai citato), si dovrebbe pensare a soluzioni come ci si assembly .NET - unità atomiche di codice che possono essere implementate separatamente dagli altri. Utilizzando upgradesolution causerà un redeploy di tutte le funzionalità contenute - se nulla è cambiato, allora nulla dovrebbe cambiare per i siti che utilizzano tale funzione. Ma, se questo vi rende nervosi, pensare di dividere in su.

Answer 3

UpgradeSolution è davvero a portata di mano se si sta solo aggiornando l'assemblaggio e lasciando intatti i file provisioning.

Se non si specifica -local poi upgradesolution eseguirà un iisreset completo in tutta l'infrastruttura. Questo è veramente degno di nota per quando si sta pianificando il momento giusto per eseguire gli aggiornamenti.