+
Come creare Feature distribuibili senza essere sviluppatori
Pubblicato il: 18/04/2010
Da: Riccardo Celesti
Lingua: Italiano

Chiariamo, non sto diventando uno sviluppatore e questo articolo non è rivolto a loro :) Questo articolo è invece dedicato a tutti quei site builder che all’improvviso si trovano ad aver disperatamente bisogno di “pacchettizzare” la loro soluzione e non hanno un “Claudio” o un “Roberto” sotto mano. Per fare un esempio di un esigenza reale che ho riscontrato sul campo un bel giorno ho avuto bisogno di creare una site definition per un publishing site che utilizzasse Content Type e Page Layout custom nella page library.

Conservo per il futuro la descrizione di come creare (sempre dal punto di vista di un site builder) una site definition, per passare all’argomento principale: costruire una feature. Di fatto il procedimento è “semplice”. Giuseppe Marchi ha già scritto un paio di articoli interessanti a riguardo, validissimi anche per tutti noi che preferiamo SharePoint Designer a Visual Studio. Il concetto è esattamente lo stesso; la nostra feature sarà composta da due file xml: feature.xml ed elements.xml

Feature.xml

In questo file sono valorizzate una serie di proprietà che descrivono il nostro il nostro pacchetto, alcune sono obbligatorie altre facoltative, diamogli un occhiata più da vicino!

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="
http://schemas.microsoft.com/sharepoint/"
    Id="2F8FECAB-9BBD-425d-88B7-3AE6113D9847"
    Title="Green Team Content Type Binding Feature"
    Description="This feature associates content types to existing SharePoint lists."
    Scope="Web"
    Hidden="True"
    Version="1.0.0.0">
    <ElementManifests>
        <ElementManifest Location="elements.xml" />
    </ElementManifests>
</Feature>

 Title e Description sono proprietà facoltative che ci aiutano, una volta che la feature è disponibile nel nostro sito a capire quali funzionalità mette a disposizione questo pacchetto. Title accetta stringhe alfanumeriche di massimo 255 caratteri mentre il limite è più alto per la proprietà Description (ok, ma non scriveteci un saggio sulle energi rinnovabili :)).

Hidden, altra proprietà facoltativa, identifica se questa feature debba essere visibile o meno dall’interfaccia grafica, molto utile quindi se si vuole evitare che questa venga disattivata, anche solo per errore. I valori impostabili sono True o False.

Scope, proprietà obbligatoria, identifica l’ambito di applicazione della nostra feature. I valori accettati sono: Web, Site, WebApplication, Farm. Nel nostro caso lo scope è Web, il sito. Il nostro intento è infatti associare uno o più content type alla page library al momento della creazione di un sito.

Ho tenuto per ultima la proprietà Id per un motivo ben preciso. Intanto, anche se mi sembra superfluo dirlo, è una proprietà obbligatoria che rappresenta l’identificativo univoco della nostra feature in formato “Globally Unique IDentifier”, il famigerato GUID. Tutti noi lo conosciamo, per un motivo o per l’altro, ma forse non tutti sanno come ottenerne uno valido (no, non credo che scrivere caratteri a caso sia considerato valido :)). In realtà è molto più semplice di quanto si possa immaginare, si può utilizzare un tool apposito. Sicuramente ci saranno “n” altri modi, io mi trovo comodo con GUIDGen, utility molto semplice che permette la generazione di GUID in quattro formati diversi. Registry Format è perfetto per i nostri scopi.

Per un approfondimento su tutte le proprietà a disposizione nel file feature.xml vi suggerisco questa pagina su MSDN.

Il tag ElementManifests contiene i riferimenti al secondo (e potenzialmente al terzo, al quarto, al quinto, …) file xml, Elements.xml, nel quale sono descritte le funzionalità che devono essere implementate.

Elements.xml

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="
http://schemas.microsoft.com/sharepoint/" >
    <ContentTypeBinding ContentTypeId="0x010100C568DB52D9D0A14D9B2FDCC96666E9F200

7948130EC3DB064584E219954237AF3900

242457EFB8B24247815D688C526CD44D00

0263D5D61C5E004EA2049803F68B4CE5" ListUrl="Pagine" />
    <ContentTypeBinding ContentTypeId="0x010100C568DB52D9D0A14D9B2FDCC96666E9F200

7948130EC3DB064584E219954237AF3900

242457EFB8B24247815D688C526CD44D00

97B12BEB5662FE489765B2130B1A1FD3" ListUrl="Pagine" />
    <ContentTypeBinding ContentTypeId="0x010100C568DB52D9D0A14D9B2FDCC96666E9F200

7948130EC3DB064584E219954237AF3900

242457EFB8B24247815D688C526CD44D00

A0ECD8E2E8731442A557674F674285F3" ListUrl="Pagine" />
    <ContentTypeBinding ContentTypeId="0x010100C568DB52D9D0A14D9B2FDCC96666E9F200

7948130EC3DB064584E219954237AF3900

242457EFB8B24247815D688C526CD44D00

CAB2EE5F60E12343ADB4A5139709B8DB" ListUrl="Pagine" />       
</Elements>

L’esempio riportato qui sopra è molto semplice. ContentTypeBinding permette di automatizzare l’associazione di un ContentType ad una lista. Il content type è indicato tramite il suo Id in ContentTypeId, mentre la lista a cui associarlo è indicata nella proprietà ListUrl, tutto qui :). Come dite? Come recupero l’id di un content type? Anche in questo caso le possibilità sono diverse. Possiamo innanzi tutto leggerlo nell’url della pagina di modifica del content type stesso oppure, avendo accesso al server, possiamo utilizzare SharePoint Inspector, grazie al quale possiamo avere accesso ad un sacco di “numeri” interessanti.

A questo punto abbiamo quindi i nostri due file, feature.xml che ci dice come funzionerà la nostra feature ed elements.xml che ci dice cosa farà. Come possiamo creare il nostro pacchetto wsp da distribuire ai nostri “BFF” IT Pro? In questo caso ci viene in aiuto WSPBuilder che, come suggerisce il suo nome, si occupa della creazione pacchetti WSP.

WSPBuilder

In questo articolo non prenderò in considerazione tutte le opzioni a disposizione di questo tool, lascio a voi l’approfondimento, cercherò di tracciare le operazioni base per raggiungere il nostro obbiettivo. Attenti alla versione per piattaforme x64, utilizza una dll specifica scaricabile dal sito del progetto su CodePlex.

1.   Nella cartella dove si trova il file wspbuilder.exe, replicare la struttura della “12 hive” a partire dal folder “12” (es. “12\Template\Features\LaVostraFeature”);

2.   Copiate nella directory “LaVostraFeature” i due file xml che abbiamo creato in precedenza: feature.xml e elements.xml;

3.   Aprite una shell di command prompt e puntate alla directory che contiene il file wspbuilder.exe;

4.   Digitate wspbuilder.exe –WSPName “ilNomeDellaVostraFeature.wsp”;

5.   Voilà, nella root della directory comparirà la vostra feature pronta per il deploy!

Come ho anticipato WSPBuilder ha molto opzioni a disposizioni, quella che ho descritto è solo il punto di partenza, quindi cosa aspettate?




Tags


Destinatari


Prodotti

Microsoft SharePoint Server 2010
SharePoint Foundation 2010


Bookmark and Share