Embed Size (px)
Citation preview
1. Beta 2
Le novità di Visual Studio 2010 Beta 2 per SharePoint 2010 Data: 11/29/2009Categoria: Sharepoint
Codice d'esempio
La nuova versione di Visual Studio porta con se tante novità per gli sviluppatori SharePoint. Nelle versioni precedenti, siamo sempre stati abituati a dover installare degli add-in che fornissero le funzionalità di base per lo sviluppo di personalizzazioni sulla piattaforma di collaborazione Microsoft come i Visual Studio tools for SharePoint, WSP Builder o gli Smart Templates. Altrimenti, era necessario procedere con la creazione manuale di tanti oggetti come web part, handler, feature e soluzioni. Con Visual Studio 2010 invece, lo sviluppatore SharePoint ha tutto quello di cui ha bisogno: nuovi template specifici per ogni tipo di personalizzazione, un nuovo designer per la costruzione di feature e soluzioni, un nuovo set di configurazioni per progetti, una finestra per la visualizzazione del contenuto di una o più web application SharePoint e nuove funzionalità per il packaging dei componenti e per il deploy. Il tutto integrato direttamente all'interno dell'IDE di sviluppo, senza quindi dover installare alcun tipo di componente aggiuntivo. In fase di installazione, infatti, è possibile scegliere di installare o meno gli strumenti di sviluppo per SharePoint che ora fanno parte del pacchetto di Visual Studio 2010.
Una volta installati, avremo a disposizione tutte le nuove funzionalità per gli sviluppatori SharePoint; novità che vedremo ora nel dettaglio.
Nuovi template
All'interno dei tools per SharePoint, sono stati introdotti una serie di template per lo sviluppo delle normali personalizzazioni che abbiamo la possibilità di installare all’interno di SharePoint. Sono presenti template sia per lo sviluppo sulla versione 2007 del prodotto (quindi anche su Windows SharePoint Services 3.0) sia per lo sviluppo sulla nuova versione 2010 (supportando SharePoint Server e SharePoint Foundation). Scegliendo di creare un nuovo progetto, infatti, l'IDE di sviluppo ci propone tale elenco dividendolo tra le due versioni appena citate e filtrando i template in base alla versione del .NET Framework scelta dall’utente.
Come è possibile vedere dalla figura, abbiamo template per la creazione di:
Visual Web Part (la nuova tipologia di web part introdotta in SharePoint 2010) Code Web Part (le normali web part a cui siamo abituati tutt'ora) Workflow (sia sequenziali che a stati) List definition Site definition Event handler Content type Modello per i Business Data Services (ex Business data catalog) Progetti SharePoint vuoti
Inoltre, è possibile anche importare all'interno di Visual Studio soluzioni (.wsp) e workflow creati in precedenza dell'arrivo delle versioni 2010 di entrambi i prodotti, in modo tale da poterle modificare all'interno del nuovo ambiente e poter usufruire di tutte le nuove funzionalità.
Aggiunte al Server Explorer
Un'altra delle mancanze fondamentali di tutti gli add-in di sviluppo per SharePoint è sempre stata una visualizzazione generale di tutto il contenuto strutturale di una o più web application. Come contenuto è da intendersi il numero di siti creati, le liste e i relativi campi, le feature, i content type, le definizioni di sito e di liste installate e i workflow presenti. Tale visualizzazione è stata aggiunta all'interno della toolbox "Server Explorer". Qui è possibile aggiungere una o più web application, specificandone l'indirizzo, per poter poi visualizzare la struttura ad albero degli oggetti creati al suo interno e le relative proprietà di ognuno di essi (tramite la normale finestra delle proprietà di Visual Studio). Una visualizzazione di questo tipo permette allo sviluppatore di capire dove installare le proprie personalizzazioni e come svilupparle per raggiungere gli scopi prefissati. Per fare un esempio molto semplice, sotto ogni lista sono presenti sia l'elenco delle relative viste che quello dei vari campi utilizzati, fornendone sia il nome visualizzato ("display name") che il nome interno ("internal name"), così che possano essere utilizzati all'interno del progetto SharePoint corrente. In figura è possibile vedere l'albero espanso di un’installazione SharePoint 2010.
Fino ad oggi, per eseguire queste operazioni di ispezione della struttura di web application e siti SharePoint era necessario appoggiarsi a strumenti esterni all'IDE di sviluppo. Tra i più famosi possiamo citare SharePoint Inspector o SharePoint Manager.
Feature designer
Per quanto riguarda invece lo sviluppo di feature SharePoint, gli strumenti messi a disposizione dai tools for SharePoint per Visual Studio 2008, per quanto sicuramente efficaci per il raggiungimento di risultati di base, risultavano però poco ferrati sulla creazione di feature complesse, composte da più file di configurazione secondari, file di risorse e moduli, obbligando quindi lo sviluppatore alla creazione manuale della struttura xml della feature principale e di tutti i file secondari. Chiaramente queste operazioni erano a forte rischio di errori di sintassi o di referenze. In Visual Studio 2010 questa mancanza è stata sopperita con la fruizione di un nuovo designer visuale per la costruzione di feature e del relativo package di progetto, che
attraverso un'interfaccia grafica davvero user-frienly, è in grado di permettere all'utente finale di scegliere quali dei componenti facenti parte del progetto dovranno essere installati tramite la feature, quale dovrà essere il suo scope, quali le dipendenze e i campi testuali di descrizione e titolo. Assieme a questo nuovo designer, è stata aggiunta una toolbox per la visualizzazione degli elementi che dovranno essere inseriti all’interno del package finale di progetto (la soluzione .wsp); la nuova toolbox è stata denominata "Packaging Explorer".
Packaging del progetto
Nuove funzionalità sono state aggiunte anche a tutto il meccanismo di compilazione e deploying dei componenti all'interno di SharePoint. E' ancora presente la possibilità di effettuare l'installazione delle proprie personalizzazioni direttamente dall'IDE di sviluppo e procedere poi con le normali operazioni di debug. In questo ambito, se Visual Studio 2010 è installato nel medesimo ambiente in cui è installato SharePoint (e ricordiamo che dalla versione 2010 SharePoint può essere installato anche su Windows 7), non è più necessario attaccarsi al processo del web server per procedere poi al debugging dei propri componenti, ma tale operazione è disponibile direttamente scegliendo il tasto F5. L'aggiunta principale però è stata sicuramente quella del packaging del progetto. Infatti ora si ha la possibilità di creare la struttura del proprio package (che in sostanza è il nuovo nome dato alle soluzioni SharePoint) direttamente all'interno di Visual Studio e di scegliere di compilarlo in un unico file con estensione .wsp, per poi procedere con l'installazione all’interno di altre farm SharePoint.
Il comando "Package" è disponibile sempre all’interno del menu "Build".
Configurazioni di progetto specifiche per SharePoint
Infine, è stata aggiornata la maschera delle proprietà dei progetti con l'aggiunta di un nuovo tab specifico per SharePoint. Al suo interno è stata inserita la gestione degli eventi "pre-deployment" e "post-deployment" così da permettere allo sviluppatore di creare dei comandi da eseguire prima o dopo il deploy delle proprie personalizzazioni. Fino ad oggi, era necessario crearsi degli script a parte per il compimento di operazioni di questo tipo, da eseguire a mano dopo aver lanciato il deploy da Visual Studio.
Conclusioni
In questo articolo abbiamo visto una rapida panoramica di quanto ci offre la nuova versione di Visual Studio (attualmente in versione Beta 2) per lo sviluppo di personalizzazioni SharePoint. Sicuramente tutti i cambiamenti apportati risultano veramente utili in quanto sono frutto di un'attenta ricerca di tutte quelle mancanze proprie degli strumenti di sviluppo utilizzati fin'ora. In più, sono tutte funzionalità di cui si può usufruire direttamente dal medesimo ambiente, senza doversi appoggiare su prodotti esterni e questo risulta sicuramente un punto vincente.
Silverlight creation experience in SharePoint 2010 All'interno di SharePoint 2010, Silverlight è totalmente integrato e presente di default attraverso un paio di web part di base (presenti sia nella versione Server che in SharePoint Foundation), una web part per la visualizzazione grafica dell'organizzazione della propria azienda (presente solo in SharePoint Server 2010) e un meccanismo per la scelta del template con cui creare le nuove liste all'interno dei vari siti. Quest'ultima risulta davvero di notevole impatto, in quanto offre una nuova user interface veramente ricca, per la selezione delle varie tipologie di liste disponibili. Come al solito Microsoft, ha scelto il nome più sborone che poteva trovare per tale interfaccia: "the creation experience". Quindi, in una normale installazione di SharePont 2010, scegliendo l'opzione "Site Actions > More Options ..." si viene portati alla pagina di selezione del tipo di lista da creare.
Se il client con cui accede l'utente non ha installato Silverlight 3.0 (o 4.0), questa pagina risulterà di aspetto e funzionalità medesime a quanto già avevamo nella versione 2007 di SharePoint. Da notare è il fatto che il sistema si accorge della mancanza di Silverlight
nel browser dell'utente e gli propone di installarlo attraverso un alert posto in alto a sinistra della pagina.
Una volta installato, al posto della normale pagina di selezione del template di lista, SharePoint renderizzerà una finestra modale che conterrà il nuovo controllo Silverlight utile a fornire all'utente finale una scelta del template di lista molto più immediata e gradevole. Il controllo è visibile in questa figura, ma dal vivo vi assicuro che è veramente bello !
Questa è una delle integrazioni già disponibili tra SharePoint 2010 e Silverlight. A breve vedremo anche tutto il resto non preoccupatevi..
I nuovi event receivers di SharePoint 2010 Data: 12/18/2009Categoria: Sharepoint
Codice d'esempio
Gli event handler, all'interno dell'architettura di SharePoint sono da sempre stati uno degli strumenti più utilizzati dagli sviluppatori, in quanto permettono la personalizzazione delle normali procedure che l'utente finale effettua tramite interfaccia grafica, senza che quest'ultimo si accorgo di effettivi cambiamenti all'interfaccia stessa. In SharePoint 2010, l'elenco degli eventi disponibili è notevolmente aumentato. Abbiamo infatti nuovi eventi riguardanti le operazioni effettuate dal motore di workflow, da quello di provisioning e da quello di incoming delle mail. Vediamoli in dettaglio.
List events Per quanto riguarda le operazioni effettuate su istanze di liste, sono stati aggiunti 4 nuovi eventi utili ad effettuare operazioni custom a fronte di un'aggiunta di una nuova lista o di una cancellazione.
A field was added
A field is being added
A field was removed
A field is being removed
A field was updated
A field is being updated
A list is being added
A list is being deleted
A list was added
A list was deleted
List item events Per quanto riguarda, invece, le operazioni effettuate su singoli elementi, è stato aggiunto un solo evento riguardante la reazione da parte del singolo elemento ad una chiamata dal contesto. In parole povere, questo evento viene scatenato quando viene richiamata la classe SPContext all'interno di altri eventi sempre relativi all'elemento.
An item is being added
An item is being updated
An item is being deleted
An item is being checked in
An item is being checked out
An item is being unchecked out
An attachment is being added to the item
An attachment is being removed from the item
A file is being moved
An item was added
An item was updated
An item was deleted
An item was checked in
An item was checked out
An item was unchecked out
An attachment was added to the item
An attachment was removed from the item
A file was moved
A file was converted
The list received a context event
List e-mail events Su liste configurate per la ricezione di messaggi e-mail è stato, finalmente, aggiunto un evento specifico appunto per la ricezione della mail. Prima era necessario gestire gli eventi ItemAdding o ItemAdded effettuare il parsing della mail e controllare manualmente gli allegati.
The list received an e-mail message
Workflow events Questi sono gli eventi che mi ha fatto più piacere trovare all'interno di SharePoint 2010. Eventi per gestire le operazioni di inizio e fine di uno o più workflow.
A workflow is starting
A workflow was started
A workflow was postponed
A workflow was completed
Web events Per quanto riguarda invece, siti e site collection, sono stati aggiunti due eventi (il sincrono e il rispettivo asincrono) per lanciare operazioni personalizzate a fronte del provisioning di un nuovo sito SharePoint 2010.
A site collection is being deleted
A site is being deleted
A site is being moved
A site is being provisioned
A site collection was deleted
A site was deleted
A site was moved
A site was provisioned
Ma la cosa più bella in assoluto, è la possibilità di creare questi eventi direttamente all'interno di Visual Studio 2010 attraverso uno dei suoi template di progetto o elemento. Il template in questione è il template "Event receiver", che prima fa scegliere all'utente finale quali degli eventi disponibili vuole gestire, poi in base alla scelta fatta, crea tutte le
strutture di configurazione XML per gli eventi e i relativi file di codice (.cs o .vb) con la dichiarazione dei gestori degli eventi selezionati.
In allegato trovate un progetto Visual Studio 2010 con tutti i nuovi eventi gestiti (senza alcun tipo di implementazione però :) Questo articolo è stato scritto sulla versione Beta 2 di SharePoint 2010 e Visual Studio 2010
L'opzione di menu "SharePoint Mapped folder" di Visual Studio 2010Riguardo le principali novità per sviluppatori SharePoint 2010, ne abbiamo parlato già nel relativo articolo. Una piccola cosa che ho tralasciato è la presenza di nuove voci di menu, all'interno del menu "Add", utilizzato solitamente per l'inserimento di nuovi elementi all'interno della soluzione. Queste, permettono allo sviluppatore di mappare la directory "IMAGES", la directory "LAYOUTS" o un'altra delle directory presenti sotto il percorso:
C:\program files\common files\microsoft shared\web server extensions\14\
all'interno della struttura del proprio package di progetto.
Così facendo, tutti i file posti in tali cartelle mappate, verrano automaticamente inseriti all'interno della soluzione ed installati sul server SharePoint 2010, nei percorsi definiti dai relativi mapping. In modo tale da poter essere disponibili per eventuali componenti personalizzati (come list o site definition, web part, ecc...) o vere e proprie applicazioni SharePoint. La medesima funzionalità appena descritta, non era presente nei tools per Visual Studio legati alla versione 2007 di SharePoint, mentre era disponibile una volta installati uno degli add-in tra WSPBuilder o gli Smart Templates.
Errore: "Failed to create sample data" durante l'installazione di SharePoint 2010Installando la beta di SharePoint 2010, mi sono scontrato tutte le volte con questo errore:Failed to create sample Data.
An exception of type Microsoft.Office.Server.UserProfiles.UserProfileException was thrown. Addictional exception information: Unrecognized attribute 'allowInsecureTransport'. Note that attribute names are case-sensitive (C:\Program Files\Common Files\Microsoft Shared\Web Server Extentions\14\WebClients\Profile\
client.config line 56)
visibile anche in figura:
Per risolvere il problema, basta solamente aprire il file client.config specificato nelle informazioni dettagliate dell'errore e togliere tutte le occorrenze dell'attributo "allowInsecureTransport". Fatto questo, è necessario far ripartire a mano il Configuration Wizard di SharePoint 2010.
2. Business Connectivity Services
Screencast: SharePoint 2010 Business Connectivity Services
Continua questa piccola serie di mini-screencast riguardo le novità presenti su SharePoint 2010. Dopo la funzione di validazione su liste, questa è la volta dei Business Connectivity Services (BCS), tecnologia utile a leggere dati da fonti esterne a SharePoint e presentarli tramite le
nuove interfaccie della piattaforma di collaborazione Microsoft. In parole povere i BCS sono una versione molto evoluta del Business Data Catalog di MOSS 2007, che risulta però disponibile anche in SharePoint Foundation 2010, la versione di SharePoint disponibile grauitamente con una licenza Windows Server. Questo il link diretto al video: http://www.peppedotnet.it/Media/SharePoint 2010 Business Connectivity Services.aspx
3. Liste4. Screencast: SharePoint 2010 list validation 5. Oggi ho inserito un nuovo screencast sotto la sezione "Media" di
peppedotnet. E' un breve video sull'utilizzo della nuova funzionalità di validazione di liste e colonne presente su SharePoint 2010. Se può interessare, ecco il link diretto:
http://www.peppedotnet.it/Media/SharePoint%202010%20List%20validation.aspx
Tale funzionalità ci permette di scrivere velocemente delle formule di validazione del contenuto di una o più colonna di una lista SharePoint, senza dover scrivere dei campi custom o degli event handler (cosa che invece era d'obbligo con MOSS 2007 o WSS 3.0).
Provisioning di un campo RichText in SharePoint 2010 Un campo di tipo RichText in SharePoint non è altro che un campo multilinea con abilitato l'editor di testo completo per la rappresentazione di contenuti "ricchi", quindi testi formattati, link, immagini, tabelle, ecc.. Per effettuare il provisioning di un campo del genere all'interno delle nostre list definition o all'interno dei nostri content type, basta creare un campo di tipo "Note" ed aggiungere le proprietà "RichText" e "RichTextMode", valorizzandole rispettivamente a "TRUE" e "FullHtml". Come si suol dire, un esempio vale più di mille parole.. ecco quindi la sintassi del nostro campo:
<Field ID="8EAA0ED0-A045-43AD-BA82-44CFAF312908"
Type="Note"
DisplayName="Sample Rich Text Field"
Name="SampleRichTextField"
StaticName="SampleRichTextField"
Group="PeppeDotNet.it - Sample Fields"
RichText="TRUE"
RichTextMode="FullHtml"
Sealed="FALSE"
SourceID="http://schemas.microsoft.com/sharepoint/v3" />
Se inseriamo questa definizione di campo all'interno di una feature e la attiviamo (o a livello di site collection o a livello di singolo sito), troveremo il nostro campo di tipo RichText tra le site column disponibili.
Come potete vedere, il tipo di formattazione del testo specificato è proprio "Enhanced rich text (Rich text with pictures, tables and hyperlinks)".
Se poi decidiamo semplicemente di inserire il nostro campo all'interno di una lista SharePoint 2010 o se abbiamo intenzione di creare un content type ed inserirci il riferimento al nostro campo di tipo RichText, avremmo a disposizione l'editor di testo avanzato all'interno della barra dei ribbon, in fase di inserimento o di modifica.
A titolo d'esempio, ho creato una soluzione SharePoint 2010 contenente il campo di tipo RichText, un content type d'esempio e una list definition creata a partire da questo content type. Trovate i sorgenti a questo indirizzo: http://www.peppedotnet.it/zip/PeppeDotNet.Provisioning.RichText.zip
4. Ribbon
Il nostro primo Ribbon per SharePoint 2010 La customizzazione dell'interfaccia di SharePoint 2010 può ritornarci molto utile per poter effettuare operazioni su liste ed elementi o per estendere il normale comportamento di SharePoint in modo da aggiungere funzionalità personalizzate, utili alle nostre applicazioni. Una delle personalizzazioni che possiamo fare è lo sviluppo di un Ribbon
personalizzato da poter aggiungere alla barra dei Ribbon presente nel layout di default della nuova versione di SharePoint. Innanzitutto, è molto importante sapere che risulta una best practices utilizzare i Ribbon per tutte quelle operazioni che in MOSS 2007/WSS 3.0 abbiamo fruito ai nostri utenti attraverso le custom action. In generale poi, ci viene utile sviluppare un Ribbon se vogliamo fare operazioni su liste e singoli o multipli elementi di liste.
Detto questo, per la definizione di un Ribbon all'interno di Visual Studio 2010 dobbiamo creare un progetto di tipo "Empty SharePoint Project" e scegliere di aggiungere un nuovo elemento di tipo "Empty element".
Questa tipologia di template contiene un file xml vuoto all'interno del quale possiamo procedere con la definizione del nostro Ribbon. Come vi dicevo, il legame tra un Ribbon e le custom action che abbiamo conosciuto in MOSS 2007 è molto importante, infatti per la definizione del nostro primo Ribbon personalizzato utilizziamo comunque il tag "CustomAction". Ma vediamo subito l'esempio, che vale sicuramente più di mille parole.
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction Id="HelloWorld"
Title="Hello World"
Location="CommandUI.Ribbon"
RegistrationType="List"
RegistrationId="101">
<CommandUIExtension>
<CommandUIDefinitions>
<CommandUIDefinition Location="Ribbon.Documents.Manage.Controls._children">
<Button Id="Ribbon.HelloWorld"
TemplateAlias="o1"
Command="HelloWorld"
LabelText="Hello world"/>
</CommandUIDefinition>
</CommandUIDefinitions>
<CommandUIHandlers>
<CommandUIHandler Command="HelloWorld"
CommandAction="javascript:alert('Hello world from ribbon !");" />
</CommandUIHandlers>
</CommandUIExtension>
</CustomAction>
</Elements>
Come potete vedere, proprio come le custom action della precedente versione di SharePoint, possiamo scegliere di inserire il nostro Ribbon all'interno della relativa barra (tramite l'attributo "Location"), il contesto in cui il nostro Ribbon dovrà apparire (attraverso gli attributi "RegistrationType" e "RegistrationId") e, novità rispetto alla vecchia versione, possiamo definire quale dovrà essere l'estensione all'interfaccia che il nostro Ribbon andrà a rappresentare.
L'estensione non è altro che un singolo controllo o una serie di controlli (nel nostro esempio un semplice bottone) che decidiamo che dovranno essere visualizzati all'interno della barra dei Ribbon, in uno dei vari tab a disposizione e che forniscano delle azioni personalizzate agli utenti finali. Nell'esempio, ho scelto di posizione la mia estensione all'interno del tab "Douments" presente in tutte le Document Library di SharePoint 2010 e all'interno del gruppo "Manage". Questa scelta viene specificata all'interno dell'attributo "Location" proprio dell'elemento "CommandUIDefinition" che rappresenta la mia estensione.
In generale, per inserire i nostri Ribbon all'interno dei vari tab e dei vari gruppi, vale la seguente regola:
Ribbon.[Tab].[Group].Controls._children
Se volete la lista di tutti gli identificativi dei tab e dei gruppi che avete a disposizione, potete andare all'interno della documentazione a questo indirizzo: http://msdn.microsoft.com/en-us/library/ee537543.aspx
Poi, ad ogni controllo (bottone, checkbox o altro che sia..) presente all'interno della nostra estensione all'interfaccia di SharePoint, possiamo legare uno specifico comando. Questo comando sarà una o più istruzioni JavaScript che abbiamo la possibilità di definire all'interno dell'attributo "CommandAction" dell'elemento "CommandUIHandler", utile a definire appunto il comportamento che dovrà avere il nostro ribbon a fronte di un'operazione da parte dell'utente su di esso.
Non mi dilungo di più perchè di cose da dire ce ne sono davvero tante e dovrei riprenderle tutte nei prossimi post o in qualche articolo pubblicato da
SharePointCommunity. Vi ricordo, che se volete un template di progetto già fatto per la scrittura di Ribbon, lo potete trovare all'interno della Code Gallery di Microsoft a questo indirizzo: http://code.msdn.microsoft.com/vsixforsp
Gestione della posizione dei controlli inseriti nella barra dei Ribbon di SharePoint 2010 Come abbiamo visto dal nostro primo esempio, possiamo aggiungere i nostri Ribbon personalizzati ad uno specifico tab ed uno specifico gruppo, specificando il corretto valore all'interno dell'attributo "Location". Se non definiamo nient'altro, gli elementi facenti parte del nostro Ribbon (bottoni, checkbox, ecc...) verranno visualizzati come ultimi nel gruppo in cui il Ribbon è stato inserito.
Nota: In questo senso, è necessario però definire bene il concetto di "ultimo", in quanto questi controlli saranno visualizzati dopo tutti quelli definiti con il medesimo "TemplateAlias" (nei prossimi post daremo una spiegazione anche all'utilità di questo attributo).
Come possiamo vedere in figura, il gruppo "Manage" del tab "Documents" (proprio di ogni Document Library appartenente ad un sito SharePoint 2010), vede già la presenza di due controlli con l’attributo "TemplateAlias" valorizzato a "o1". Questi sono i controlli per la visualizzazione delle proprietà di un documento o per la loro modifica. L'esempio visto nel precedente post infatti, posiziona il nostro Ribbon personalizzato con etichetta "Hello world", subito dopo questi due.
Se vogliamo invece spostare il nostro bottone personalizzato prima di tutti gli altri (o in qualsiasi altra posizione), dobbiamo dare un valore intero all'attributo "Sequence" del controllo che vogliamo posizionare.
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction Id="Ribbon.HelloWorld"
RegistrationId="101"
RegistrationType="List"
Location="CommandUI.Ribbon"
Title="Hello world ribbon">
<CommandUIExtension>
<CommandUIDefinitions>
<CommandUIDefinition Location="Ribbon.Documents.Manage.Controls._children">
<Button Id="Ribbon.HelloWorld.Button"
LabelText="Hello world"
TemplateAlias="o1"
Sequence="1"
Command="HelloWorld" />
</CommandUIDefinition>
</CommandUIDefinitions>
<CommandUIHandlers>
<CommandUIHandler Command="HelloWorld"
CommandAction="javascript:alert('Hello world from Ribbon !');" />
</CommandUIHandlers>
</CommandUIExtension>
</CustomAction>
</Elements>
Così, scegliendo di valorizzare tale attributo con il valore 1 (o comunque un numero minore di 10), abbiamo deciso che il nostro bottone custom deve essere renderizzato come primo all'interno del gruppo "Manage" del tab "Documents".
Specificando invece il valore 11 (quindi maggiore di 10 e minore di 20), il nostro Ribbon custom verrà posizionato tra il controllo di visualizzazione delle proprietà e quello di modifica.
Questo perchè ogni Ribbon già presente nella barra, ha un valore dell'attributo "Sequence" che parte da 10 (per il primo controllo da sinistra) e va avanti di 10 in 10 per ogni controllo successivo. Nel nostro esempio, i controlli presenti all'interno del gruppo "Manage" del tab "Documents" hanno i seguenti valori per il campo "Sequence":
View properties - 10 Edit properties - 20
Per visualizzare i corretti valori di ognuno dei controlli presenti all'interno della barra dei Ribbon e del gruppo specifico che abbiamo scelto per la visualizzazione della nostra personalizzazione all'interfaccia di SharePoint 2010, possiamo spulciare il file di definizione "CMDUI.XML" presente all'interno del percorso:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\GLOBAL\XML
Ecco infatti, come sono definiti i due controlli in questione:
<Button Id="Ribbon.Documents.Manage.ViewProperties"
Sequence="10"
...
TemplateAlias="o1" />
<Button Id="Ribbon.Documents.Manage.EditProperties"
Sequence="20"
...
TemplateAlias="o1" />
Se avete famigliarità con le custom action introdotte in WSS 3.0/MOSS 2007, vi sarete sicuramente accorti che il concetto di sequenza della visualizzazione delle azioni è esattamente il medesimo, con l'unica differenza che in questo specifico caso viene applicato alla barra dei Ribbon e non ai vari menu contestuali presenti all'interno dell'interfaccia di SharePoint. Nel prossimo post vedremo invece quali sono i template che abbiamo a disposizione per il rendering di un controllo posto all'interno di un gruppo già presente nella barra dei Ribbon di SharePoint 2010.
Template di un controllo Ribbon posto all'interno di un gruppo pre-esistente Durante la customizzazione della barra dei ribbon, oltre a dover specificare il tab e il gruppo in cui i controlli relativi al nostro Ribbon personalizzato dovranno essere visualizzati (come abbiamo visto nel primo post di questa serie dedicata ai Ribbon), dobbiamo specificare anche il modo in cui questi controlli dovranno essere renderizzati. Per farlo, ogni controllo che possiamo inserire all'interno dell'estensione all'interfaccia di SharePoint che stiamo sviluppando, espone l'attributo TemplateAlias. Questo attributo serve a specificare l'identificativo del template che deve essere utilizzato per dare una larghezza ed una grandezza al controllo in questione, quando un particolare template è stato applicato al gruppo in cui abbiamo deciso di inserire il nostro Ribbon personalizzato. Nel primo esempio, abbiamo applicato al bottone il template con alias "o1". Questo alias permette al sistema di rendering della barra dei Ribbon di SharePoint 2010 di dare larghezza e altezza massime al bottone. Inoltre, applica al bottone stesso l'immagine il cui URL è definito all'interno dell'attributo "Image32by32".
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction Id="Ribbon.HelloWorld"
RegistrationId="101"
RegistrationType="List"
Location="CommandUI.Ribbon"
Title="Hello world ribbon">
<CommandUIExtension>
<CommandUIDefinitions>
<CommandUIDefinition Location="Ribbon.Documents.Manage.Controls._children">
<Button Id="Ribbon.HelloWorld.Button"
LabelText="Hello world"
TemplateAlias="o1"
Image32by32="/_layouts/images/PeppeDotNet/HelloWorld32by32.png"
Sequence="31"
Command="HelloWorld" />
</CommandUIDefinition>
</CommandUIDefinitions>
<CommandUIHandlers>
<CommandUIHandler Command="HelloWorld"
CommandAction="javascript:alert('Hello world from BIG Ribbon !');" />
</CommandUIHandlers>
</CommandUIExtension>
</CustomAction>
</Elements>
Il risultato di un bottone con l'attributo TemplateAlias valorizzato a "o1" lo conosciamo già.
Ma se volessimo invece visualizzare il nostro Ribbon personalizzato nel formato un pò più piccolo, dobbiamo specificare un nuovo valore per l'attributo TemplateAlias. Questo è il valore "o2", che specifica la dimensione massima del testo, la posizione e l'utilizzo dell'immagine il cui URL è definito all'interno dell'attributo "Image16by16".
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction Id="Ribbon.HelloWorld"
RegistrationId="101"
RegistrationType="List"
Location="CommandUI.Ribbon"
Title="Hello world ribbon">
<CommandUIExtension>
<CommandUIDefinitions>
<CommandUIDefinition Location="Ribbon.Documents.Manage.Controls._children">
<Button Id="Ribbon.HelloWorld.Button"
LabelText="Hello world"
TemplateAlias="o2"
Image16by16="/_layouts/images/PeppeDotNet/HelloWorld16by16.png"
Sequence="31"
Command="HelloWorld" />
</CommandUIDefinition>
</CommandUIDefinitions>
<CommandUIHandlers>
<CommandUIHandler Command="HelloWorld"
CommandAction="javascript:alert('Hello world from LITTLE Ribbon !');" />
</CommandUIHandlers>
</CommandUIExtension>
</CustomAction>
</Elements>
Una volta fatto deploy, vedremo il nostro bottone personalizzato apparire nel secondo gruppo di controlli (sempre all'inteno del gruppo "Manage" proprio del tab "Documents"), cioè assieme a tutti quei controlli con altezza minima. Volendo poi spostarlo prima, in mezzo o dopo gli altri controlli già presenti, possiamo giocare con i valori dell'attributo "Sequence" (come spiegato in questo post).
Gli alias di template visti fin'ora ("o1" e "o2") sono validi fin quando vogliamo inserire un controllo all'interno di uno dei gruppi già esistenti nella barra dei
Ribbon di SharePoint 2010. Se decidiamo invece di creare dei tab e dei gruppi personalizzati, possiamo allora definire i nostri template personalizzati per la visualizzazione dei controlli.
Le icone di un controllo personalizzato all'interno della barra dei Ribbon Nel precedente post abbiamo visto com'è possibile personalizzare la grandezza di un controllo Ribbon all'interno di un tab e un gruppo già presenti alla barra dei Ribbon. Abbiamo identificato due template principali, rispettivamente definiti dagli alias "o1" e "o2", e abbiamo visto che in base alla scelta di un template al posto dell'altro, vengono visualizzate differenti immagini a rappresentare il nostro controllo. Nel dettaglio, certi tipi di controlli possono essere rappresentati da due differenti immagini, ovviamente di diverse dimensioni:
Immagine 32 x 32: il cui URL va definito all'interno dell’attributo "Image32by32"
Immagine 16 x 16: il cui URL va definito all'interno dell’attributo "Image16by16"
I controlli che offrono la possibilità della visualizzazioni di questi due differenti formati di immagine sono i seguenti:
Button SplitButton ToggleButton FlyoutAnchor
Su qualsiasi di queste due immagini, possiamo poi definire una serie ulteriore di attributi che ne modificano la visualizzazione. Eccoli nel dettaglio:
Image32by32Class / Image16by16Class: il nome della classe CSS che verrà applicata all'immagine.
Image32by32Left / Image16by16Left: un valore negativo che rappresenta l'offset dal margine sinistro con cui deve essere renderizzata l'immagine.
Image32by32Top / Image16by16Top: un valore negativo che rappresenta l'offset dal margine alto con cui deve essere renderizzata l'immagine.
Gli ultimi due attributi vengono utilizzati da SharePoint stesso per renderizzare parti di immagini contenenti più icone utili a differenti controlli.
Altri controlli che possono essere configurati in modo da visualizzare un'immagine all'interno della barra dei ribbon sono il controllo GalleryButton (tramite il suo attributo "Image") e il controllo Label (che contiene solamente l'attributo Image16by16).
Se volete maggiori informazioni riguardo lo schema di tutti i controlli che potete inserire all'interno della barra dei Ribbon, potete consultare la documentazione on-line a questo indirizzo: http://msdn.microsoft.com/en-us/library/ff458369.aspx
Abilitare o disabilitare un controllo di un Ribbon in base alla selezione dell'utenteSe decidiamo di personalizzare la barra dei Ribbon, inserendo alcuni controlli custom in qualche particolare tab e gruppo, abbiamo anche la possibilità di decidere quando tale Ribbon dovrà o meno essere abilitato. Chiaramente, quello che verrà abilitato (o disabilitato) sarà il comando che l'utente finale può eseguire facendo click sul Ribbon; poi, l'interfaccia di SharePoint 2010 si preoccuperà anche di renderizzare il Ribbon in maniera da far capire a colpo d'occhio che non è possibile eseguire operazioni sul contentuo della pagina a partire da quello specifico controllo. Ad effettuare il controllo vero e proprio invece, sarà una funzione Javascript che dovrà essere inserita all'interno della definizione del relativo comando del Ribbon. Nello specifico, questa funzione dovrà essere inserita allÂ’interno dellÂ’attributo "EnableScript" proprio dell'elemento "CommandUIHandler" e dovrà ritornare un valore booleano, in modo che lÂ’interfaccia di SharePoint 2010 riesca a capire quando abilitare il controllo e quando invece disabilitarlo. Per fare in modo di abilitare o disabilitare il controllo del nostro Ribbon in base alla selezione da parte dell'utente sugli elementi di una lista, dobbiamo utilizzare il Client Object Model per ECMAScript offerto da SharePoint 2010 e le sue classi per la selezione. Vediamo come:
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction Id="Ribbon.HelloWorld"
RegistrationId="101"
RegistrationType="List"
Location="CommandUI.Ribbon"
Title="Hello world ribbon">
<CommandUIExtension>
<CommandUIDefinitions>
<CommandUIDefinition Location="Ribbon.Documents.Manage.Controls._children">
<Button Id="Ribbon.HelloWorld.Button"
LabelText="Hello world"
TemplateAlias="o1"
Image32by32="/_layouts/images/PeppeDotNet/HelloWorld32by32.png"
Sequence="31"
Command="HelloWorld" />
</CommandUIDefinition>
</CommandUIDefinitions>
<CommandUIHandlers>
<CommandUIHandler Command="HelloWorld"
CommandAction="javascript:alert('Action for only one item !');"
EnabledScript="javascript:SP.ListOperation.Selection.getSelectedItems().length == 1;"/>
</CommandUIHandlers>
</CommandUIExtension>
</CustomAction>
</Elements>
Nell'esempio, abbiamo deciso che il nostro Ribbon di prova dovrà essere abilitato solamente quando l'utente ha selezionato un singolo elemento. Nel blog del team di SharePoint trovate un'altra implementazione di questo comportamento, disponibile attraverso l'uso della funzione CountDictionary().
Nel caso in cui lÂ’utente scelga di selezionare più elementi o nel caso in cui non ne abbia scelto ancora nessuno, il pulsante risulterà qunidi disabilitato.
Questo ci permette di effettuare operazioni su singoli elementi di una lista SharePoint. Allo stesso modo, se volessimo invece effettuare operazioni su più di un elemento selezionato da una lista, dovremmo scrivere il codice che controlli che la selezione dell'utente contenga più di un singolo elemento (l'esatto contrario di quanto scritto prima).
<CommandUIHandler Command="HelloWorld"
CommandAction="javascript:alert(Action for multiple items !');"
EnabledScript="javascript:SP.ListOperation.Selection.getSelectedItems().length > 1;"/>
Questo ci permettere di effettuare la medesima operazione su più documenti (o elementi) scelti dall'utente. Infatti, la funzione SP.ListOperation.Selection.getSelectedItems(), propria del modello ad oggetti client-side per ECMAScript (di cui sicuramente vedremo un'introduzione), ritornerà una collezione di elementi contenente tutti gli oggetti che sono stati selezionati dallÂ’utente, compresi di identificativi, utili ad effettuare poi le nostre operazioni personalizzate su di essi. Nel caso di una selezione singola, quella funzione ritornerà una collezione contenente un solo elemento.
In questi esempi, abbiamo utilizzato le classi esposte dal modello ad oggetti client-side per ECMAScript per abilitare o disabilitare il nostro controllo Ribbon. Volendo, abbiamo la possibilità di fare qualsiasi altro tipo di calcolo all'interno del nostro script, utilizzando una o più funzioni, e ricordandoci sempre che la funzione principale deve ritornare un valore booleano.
<CommandUIHandler Command="HelloWorld"
CommandAction="javascript:alert('Action only for work-hours !');"
EnabledScript="javascript:function abilitaRibbon() {
var ora =
ritornaOraCorrente();
return (ora >= 9 && ora <= 18);
};
function ritornaOraCorrente()
{
var d = new Date();
return d.getHours();
}
abilitaRibbon();"/>
Nel prossimo post vedremo come spostare all'esterno del file XML di definizione del Ribbon personalizzato (quindi all'interno di un file .js specifico), tutto il codice Javascript utilizzato sia per l'abilitazione o la disabilitazione del controllo, sia per l'azione vera e propria da compiare dopo un click da parte dellÂ’utente sul controllo stesso.
TAGS: [SharePoint] [SharePoint 2010] [Ribbon] [Client Object Model]Commenti(5) - Posted @ 11/8/2010 9:25:37 AM - Categoria: Sharepoint - Permalink - Share on twitter | facebook
COMMENTI
Autore: Gabriele Del Giovine - scritto il 11/8/2010 9:54:17 AM Bell'articolo, complimenti.
Autore: Peppe - scritto il 11/8/2010 2:27:07 PM Grazie gab ! ;)
Autore: Maurizio - scritto il 7/25/2011 11:20:59 AM ciao beppe...bell'articolo...molto utile. Volevo solo chiederti una cosa. Avendo diverse librerie nel mio sito come posso fare per abilitare un gruppo
di Ribbon solo in alcune di queste e non nelle altre?
Grazie
Ciao Maurizio
Autore: Maurizio - scritto il 7/25/2011 3:29:45 PM ho risolto con qualche riga di javascript nell'EnabledScript.
ciao
Autore: Peppe - scritto il 7/25/2011 11:50:10 PM Ciao Maurizio e grazie ;) Per fare quello che ti serve, devi "giocare" con le list definition o con i content type. Così da associare il tuo ribbon custom solo a particolari liste che utilizzano le tue strutture (content type o list definition).
A presto Peppe
5. Integrazione con Visual Studio 2010
Errore: "Error occurred in deployment step 'Recycle IIS Application Pool'" Iniziando a sviluppare per SharePoint 2010 attraverso gli strumenti di sviluppo offerti da Visual Studio 2010, vi troverete sicuramente di fronte al seguente problema. Spostando un progetto da un'ambiente di sviluppo ad un altro e provando a ricompilare, l'IDE di sviluppo completerà correttamente la fase di compilazione e creazione del package, ma andrà in errore durante la fase di deploy della vostra personalizzazione su SharePoint. L'errore generato sarà di questo tipo:
Error occurred in deployment step 'Recycle IIS Application Pool': Cannot connect to the SharePoint site: http://YOUR_SITE_NAME/. Make sure that this is a valid URL and the SharePoint site is running on the local computer. If you moved this project to a new computer or if the URL of the SharePoint site has changed since you created the project, update the Site URL property of the project.
Questo perchè, alla creazione di un nuovo progetto SharePoint, Visual Studio chiede quale dev'essere l'indirizzo della site collection in cui effettuare il deploy e se lo salva all'interno delle proprietà del progetto. Spostando la soluzione e i vari file di progetto è necessario aggiornare a mano tale indirizzo.
Per farlo, dobbiamo selezionare il progetto dalla toolbox "Solution Explorer" e successivamente aprire la toolbox delle proprietà. Li troverete la proprietà "Site URL", che dovrà essere cambiata con il nuovo indirizzo della vostra site collection SharePoint 2010. State attenti ad aprire la toolbox delle proprietà (visibile in figura) e NON le proprietà del progetto tramite l'utilizzo del tasto destro del mouse.
Fatto questo, basta provare a ricompilare e rieffettuare il deploy della soluzione.
Come installare il VSeWSS upgrade tool per Visual Studio 2010 Microsoft ha rilasciato già da un pò, in versione beta, un tool per la migrazione dei progetti MOSS 2007 sviluppati tramite i VSeWSS a progetti Visual Studio 2010. Il tool è davvero ben fatto e facilita notevolmente l'upgrade delle personalizzazioni dalla vecchia versione di SharePoint alla nuova, senza la necessità di fare troppe operazioni manuali. Per installarlo però, non basta solamente scaricare l'eseguibile e lanciarlo, ma sono necessari dei passi aggiuntivi.. eccoli nel dettaglio.
1- Scaricare il tool a questo indirizzo: VSeWSS_Upgrade_Sample_Beta_20100108.msi 2- Assicurarsi di aver chiuso tutte le istanze di Visual Studio 2010 3- Avviare l'installer 4- Andare alla cartella "C:\Program Files (x86)\Microsoft\VSeWSS Upgrade" 5- Eseguire il file "VSeWSSUpgrade_Beta2_20091203.msi", che installa effettivamente il template all'interno di Visual Studio 6- Aprire il command prompt dei tool di Visual Studio 7- Eseguire il comando "devneve /installvstemplates" 8- Aprire Visual Studio 2010
Una volta eseguite queste operazioni, sarete in grado di utilizzare il tool di upgrade delle soluzioni VSeWSS a Visual Studio 2010. Questo e tanto altro ancora, nella mia sessione alla SharePoint Conference, riguardo l'aggiornamento di soluzioni MOSS 2007 a SharePoint 2010.
Come disattivare l'attivazione di feature in fase di deploy in Visual Studio 2010 Quando sviluppiamo le nostre personalizzazioni su SharePoint 2010 utilizzando gli strumenti messi a disposizione da Visual Studio 2010, ci accorgiamo che tutte le nostre feature vengono attivate in automatico ogni volta che viene lanciata l'operazione di deploy della soluzione sul sito SharePoint scelto in fase di creazione del progetto.
Questa è la configurazione di default che abbiamo all'interno dei tool di sviluppo per SharePoint 2010. Molte volte però, questa configurazione può impedire le nostre azioni di debug del codice o delle funzionalità implementate. Pensiamo solo allo sviluppo di un event receiver che gestisce gli eventi di attivazione o di disattivazione della feature. In questo caso specifico ad esempio, non siamo in grado di fare debug del nostro codice, in quanto Visual Studio 2010 non permette di effettuare l'operazione di deployment e quella di debug contemporaneamente. Proprio per ovviare a questo problema, è possibile modificare tale configurazione e scegliere di non attivare la feature in automatico. Per farlo basta entrare nelle proprietà del progetto dalla toolbox "Solution Explorer", scegliere il tab "SharePoint" e selezionare la configurazione "No Activation".
Così facendo, ad ogni successivo deployment non verranno attivate le feature della nostra soluzione in automatico, ma potremmo farlo noi da interfaccia web (o tramite l'utility STSADM o, ancora, tramite PowerShell) per poi metterci in debug del nostro codice.
Così come abbiamo potuto disabilitare l'attivazione in automatico della feature all'interno del sito SharePoint scelto in fase di creazione del progetto, abbiamo anche la possibilità di creare configurazioni personalizzate in cui inserire operazioni di deploy e retract della soluzione, reciclo degli
application pool, attivazione di feature e esecuzione di comandi pre/post deployment.
Le librerie di SharePoint 2010 possono essere usate solo su applicazioni compilate con il .NET Framework 3.5Se provate a creare un nuovo progetto con la versione 4 del .NET Framework come Target Platform e inserite la libreria Microsoft.SharePoint.dll tra le referenze del vostro progetto, vi accorgerete che tale libreria non può essere utilizzata con altre versioni del Framework se non con la versione 3.5 ! Infatti, usando una delle classi del modello ad oggetti lato server di SharePoint 2010, troverete questo errore:
System.PlatformNotSupportedException Microsoft SharePoint is not supported with version 4.0.30319.1 of the Microsoft .Net Runtime.
In altri casi, vi può succedere che subito dopo aver inserito la referenza alla dll di SharePoint tutto funzioni correttamente, intellisense e tutto il resto. Ma, alla prima compilazione, troverete tra le eccezioni scatenate la seguente:
The type or namespace name 'SharePoint' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?)
Questo purtroppo è così e basta ! Microsoft direbbe "è così by desgin". Quindi non possiamo farci niente. Se vogliamo leggere o modificare dati presenti in SharePoint da un'applicazione scritta utilizzando il .NET Framework 4.0 dobbiamo usare i webservices esposti.
TAGS: [SharePoint] [SharePoint 2010] [Object Model]Commenti(2) - Posted @ 10/6/2010 2:31:59 PM - Categoria: Sharepoint - Permalink - Share on twitter | facebook
COMMENTI
Autore: john - scritto il 10/6/2010 3:29:45 PM che sgarolata!
Autore: Luigi Panariello - scritto il 10/6/2010 4:32:14 PM Credo sia dovuto alle differenze tra i due CLR. D'altronde è anche il motivo per cui adesso ci sono due GAC: http://msdn.microsoft.com/en-us/magazine/dd727509.aspx
6. Installazione
SharePoint 2010 non supporta più l'installazione standalone su un domain controller Dalle prime installazioni della RTM di SharePoint 2010 arrivano le prime notizie.. Microsoft ha deciso di nascondere dall'interfaccia grafica dell'utility di installazione del prodotto, l'opzione di configurare SharePoint in modalità standalone da quelle macchine dove è già installato un Domain Controller, questo perchè SQL Server Express 2008 non è supportato in un Domain Controller. Non supportato, ovviamente, non significa non funzionante :)
Lanciando il setup da riga di comando, infatti, è possibile installare comunque la versione standalone di SharePoint 2010 su un Domain Controller (ovviamente fatelo SOLO su macchine di sviluppo o utilizzate per delle demo). Ecco i parametri per completare l'installazione standalone:
setup.exe /config FILES\SETUP\config.xml
Ricordo che è possibile visualizzare la lista di tutti i parametri dell'utility di installazione eseguendo il comando:
setup.exe /?Come installare una farm SharePoint 2010 utilizzando un account locale Di tanto in tanto, può capitare di dover installare SharePoint 2010 in una macchina fuori dominio e di aver bisogno di gestirne i database attraverso un'installazione di SQL Server Standard o Enterprise. Questo, è il caso in cui un'installazione di tipo standalone ci sta stretta, perchè si basa sulla versione Express di SQL. Provando quindi ad installare SharePoint in modalità avanzata e iniziando la configurazione di una nuova farm, l'utility "SharePoint Products Configuration Wizard" ci ferma immediatamente dicendo che l'utenza con cui abbiamo deciso di far girare tutti i servizi di SharePoint e che si occuperà di accedere ai vari database è un account locale e che non è possibile creare una nuova farm utilizzando un account NON di dominio. L'errore in questione è il seguente:
The specified user [USER NAME] is a local account. Local accounts should only be used in stand alone mode
Se ci pensiamo bene, SharePoint ha pienamente ragione, perchè una configurazione avanzata permette la creazione di una farm alla quale possiamo poi collegare altri server, magari per l'indicizzazione, l'invio delle mail o altro.. ed ovviamente, un account locale alla macchina in cui stiamo installando il prodotto non è in grado di "passare" tra una macchina e l'altra data la sua natura "local" (non è appartenente a nessun dominio). Se, però, siamo sicuri che la nostra macchina sarà l'unica facente parte della farm SharePoint, abbiamo la possibilità di creare comunque la nostra farm, utilizzando Powershell.
Il comando da lanciare è il comando "New-SPConfigurationDatabase", che chiederà come parametri di creazione il nome del database di configurazione, il nome del database server e l'utenza con cui accedere a questo database.
La scelta dell'utente verrà fatta tramite la finestra di login di windows.
Così facendo, verrà creato un nuovo database di configurazione di SharePoint all'interno di SQL Server che sarà la base della nostra nuova farm. Infatti, avviando nuovamente l'utility "SharePoint Products Configuration Wizard", quest'ultima si accorgerà della presenza di una farm
SharePoint e ci permetterà così di procedere con l'installazione del prodotto.
Fatto questo, abbiamo la nostra installazione di SharePoint 2010 in modalità avanzata, in una macchina a sé stante.
Come recuperare le Missing Web Part indicate nel report di upgrade a SharePoint 2010 Quando ci si prepara per un upgrade a SharePoint 2010 utilizzando la tecnica dell'attach del database di contentuo, è buona regola lanciare il comando *Test-SPContentDatabase* tramite PowerShell. Questo comando controlla il database di contenuto che abbiamo intenzione di migrare e produce un report contenente tutti gli warning relativi al processo di migrazione, così che possiamo cercare il modo migliore di correggerli. Tra i vari messaggi, ci sono anche tutti quelli riguardanti le web part mancanti sulla farm SharePoint 2010 e che invece sono presenti all'interno del database che abbiamo intenzione di migrare. Il problema è che quel report non ci indica ne l'assembly ne il nome del tipo della nostra web part mancanta, ma ci presenta un GUID, il che rende impossibile capire di
quale web part si sta parlando. Esiste però il modo per recuperare a partire da quell'identificativo, qual'è l'assembly e quale la web part mancante. Per questo ho creato un piccolo progetto su codeplex che dato l'assembly e il tipo di una web part (che possiamo tranquillamente recupare dalla pagina http://SERVERSHAREPOINT/_layouts/newdwp.aspx) genera l'identificativo della web part così come lo troviamo nel report di pre-migrazione. La generazione di questo identificativo è fatta utilizzando lo stesso algoritmo che utilizza SharePoint per generare il GUID relativo alla web part e salvarlo nel database. Questo algorimo utilizzo un hashing MD5 per computare la stringa formata dalla concatenazione del nome dell'assembly, di un pipe e del nome del tipo relativi alla web part.
string data = "Microsoft.Office.Server.Search, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" +
"|" +
"Microsoft.Office.Server.Search.WebControls.AdvancedSearchBox";
byte[] dataBytes = Encoding.Unicode.GetBytes(data);
MD5 hashAlgo = new MD5CryptoServiceProvider();
byte[] hash = hashAlgo.ComputeHash(dataBytes);
Guid hashGuid = new Guid(hash);
string WebPartID = hashGuid.ToString();
Potete scaricare il tool da codeplex seguendo questo indirizzo: http://easywebparttypeidgen.codeplex.com/
7. Personalization
Screencast: list item custom action con SharePoint Designer 2010 Una delle nuove funzionalità di SharePoint Designer 2010 è quella di permettere la creazione di custom action (o ribbon) direttamente su un'istanza di lista ed associare a tale azione un indirizzo personalizzato. Nella versione 2007 di SharePoint, per la creazione di un'azione personalizzata dovevamo creare una feature apposita e specificare lo scope per la nostra azione, se applicabile a tutte le liste, se a singole tipologie (tramite l'identificativo di una list definition) o se a singoli content type. In SharePoint 2010 invece, possiamo legare azioni custom su singole liste già create all'interno dei nostri siti SharePoint, senza dover passare per la creazione della relativa feature.
Per spiegare velocemente questa nuova funzionalità, ho registrato uno screencast che potete trovare all'interno della sezione "Media" di questo sito.
Come scrivere un event handler che effettua un redirect in SharePoint 2010 Il modello ad oggetti di SharePoint 2010 vede una novità per quanto riguarda la classe SPEventReceiverStatus. Tale classe definisce lo stato di un event handler e permette di scegliere se la sua computazione deve continuare, se
deve stopparsi lasciando all'utente un errore o se deve stopparsi "in silenzio" diciamo, quindi senza eseguire alcuna operazione sull'interfaccia grafica. Oltre a questi comportamenti, nella nuova versione del prodotto di collaborazione Microsoft, è stato aggiunto quello di poter decidere di stoppare l'evento e redirezionare l'utente su una particolare pagina (diversa quindi dalla solita pagina "errors.aspx"), così da offrire una grafica personalizzata per il messaggio d'errore o per qualsiasi altro tipo di personalizzazione. Questo comportamento è definito dal valore CancelWithRedirectUrl e, come per gli altri, può essere utilizzato solamente all'interno di eventi di tipo sincroni (quindi tutti quelli che finiscono con "ing", per intenderci), che sono gli unici la cui computazione può essere stoppata.
Vediamo quindi, che all'interno di un gestore d'evento di tipo ItemDeleting, possiamo scegliere di stoppare la cancellazione dell'elemento (proprio come abbiamo sempre fatto in MOSS 2007) e redirezionare l'utente su una pagina d'errore personalizzata. Per farlo, dobbiamo settare le proprietà Status e RedirectUrl della classe SPItemEventReceiver:
namespace PeppeDotNet.SP2010.RedirectEventReceiver
{
public class RedirectReceiver : SPItemEventReceiver
{
public override void ItemDeleting(SPItemEventProperties properties)
{
base.ItemDeleting(properties);
properties.Status = SPEventReceiverStatus.CancelWithRedirectUrl;
properties.RedirectUrl = "/_layouts/PeppeDotNet.SP2010/DeleteMessage.aspx";
}
}
}In questo esempio, con due righe di codice è stato possibile effettuare un redirect su una application page custom, posta sotto la directory "LAYOUTS". Su questa pagina è stato inserito il testo d'errore personalizzato e un pulsante per ritornare alla pagina chiamante (che utilizza il valore preso dalla querystring "Source", valore inserito in automatico dall'handler una volta che effettua il redirect).
Ed ecco il risultato:
Così facendo, possiamo effettuare delle azioni custom a fronte di una delle operazioni che l'utente finale può fare sugli elementi di una lista SharePoint 2010 ed effettuare un redirect su un secondo contesto personalizzato.
In MOSS 2007 era possibile, con qualche trucco, effettuare un redirect all'interno di un event handler, ma così come l'han fatto è decisamente molto ma molto più pulito. Forte no ? :)
Come abilitare le informazioni per il debug di un'eccezione in SharePoint 2010 SharePoint ha sempre nascosto i messaggi di errore veri e propri e tutte le informazioni relative al debug dell'errore stesso, per mantenere un buon rapporto con l'utente finale che il più delle volte si spaventa alla vista di tutte quelle scritte preferendo la solita frase "an error has occourred". Sappiamo già com'è possibile visualizzare per esteso le informazioni degli errori in WSS 3.0/MOSS 2007, modificando il file web.config proprio della web application su cui stiamo facendo operazione di debug. In SharePoint 2010 invece, è necessario modificare due differenti web.config:
1. Quello presente nella directory legata alla vostra web application SharePoint (se non cambiate il percorso di default, troverete il web.config da modificare al percorso: "[drive]:\inetpub\wwwroot\wss\virtualdirectories\[port]")
2. Quello presente all'interno della directory "LAYOUTS" posta sotto la SharePoint root (cioè il file presente al percorso: "[drive]:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS")
Quello che rimane invariato rispetto alla versione precedente di SharePoint, sono gli attributi da modificare all'interno del file web.config:
1. L'attributo "Debug" dell’elemento "Compilation" va portato a "true" 2. L'attributo "CallStack" dell'elemento "SafeMode" va portato a "true" 3. L'attributo "Mode" dell'elemento "CustomErrors" va portato a "Off"
Così facendo, la schermata di errore classico passerà da..
a..
Se volete invece maggiori informazioni sull'esecuzione della pagina, potete abilitare la developer dashboard (una delle novità si SharePoint 2010 per sviluppatori). Se volete informazioni a riguardo, ne potete trovera all'interno della documentazione: http://msdn.microsoft.com/en-us/library/ff512745.aspx
8. Client-Site API9. Introduzione alle Client-Side API di SharePoint 2010
10. E' appena stato pubblicato un mio nuovo articolo su SharePoint 2010 all'interno di SharePoint Community. E' una breve introduzione sulle API esposte dalla nuova versione di SharePoint, per lo sviluppo di applicazioni client-side che girano su Windows o all'interno del browser (Silverlight o personalizzazioni Javascript). Seguirà un secondo articolo, dove sarà possibile vedere il codice per effettuare le normali operazioni di tipo CRUD su liste SharePoint utilizzando uno dei tre modelli ad oggetti per lo sviluppo lato client (per esser precisi quello per lo sviluppo di applicazioni Windows). Qua il link all'articolo: http://www.sharepointcommunity.it/articles/Lists/Articles/DispForm.aspx?ID=11
L'introduzione delle API per la programmazione client-side sono sicuramente la novità che, personalmente, ho apprezzato di più all'interno di SharePoint 2010. Non si parla più di web services, di dover formattare e parsare tutto quell'xml per interrogare SharePoint dall'esterno e leggere i risultati delle nostre interrogazioni, il tutto mantenedo il paradigma della programmazione ad oggetti, proprio come siamo sempre stati abituati utilizzando il modello ad oggetti lato server. Il che è fantastico ! No ? :)
11. Operazioni CRUD con il Client Object Model di SharePoint 2010
12. Dopo l'articolo di introduzione sulle API per la programmazione client-side di SharePoint 2010, ecco il mio secondo articolo sul tema pubblicato su SharePoint Community. Questa volta però, è incentrato sulle operazioni di base
che si possono fare su liste SharePoint utilizzando il Client Object Model e una banalissima applicazione Windows. Ho scelto di scriverci un articolo proprio perchè le operazioni CRUD (Create, Read, Update, Delete) su liste, sono veramente le azioni che si fanno più spesso quando si sviluppano applicazioni che hanno a che fare con SharePoint e penso che sicuramente sarà utile a molti. Qui il link per l'articolo: http://www.sharepointcommunity.it/articles/Lists/Articles/DispForm.aspx?ID=12
Se volete scaricare i sorgenti invece, potete farlo direttamente da qua (sono gli stessi esempi visti all'interno della mia sessione per l'evento GroundZero di DotNetLombardia): http://www.peppedotnet.it/zip/Dev4Side.GroundZero.zip
Finalmente, sto per andare in vacanza anche io.. verso mare stupendo spero. Ci si risente tra un pò ;)
Errore "Security error" utilizzando il Client Object Model di SharePoint 2010 per Silverlight Se iniziate ad utilizzare il modello ad oggetti client-side di SharePoint 2010 per applicazioni Silverlight e provate ad istanziare un nuovo oggetto di tipo "ClientContext" passando come parametro al costruttore principale l'indirizzo di un sito SharePoint remoto (senza far girare l'applicazione Silverlight all'interno del contesto di SharePoint) ...
ClientContext context = new ClientContext("http://sharepoint2010");
//…context.ExecuteQueryAsync(...); //errore
vi troverete a fare i conti con questo errore:
{System.Security.SecurityException ---> System.Security.SecurityException: Security error. at System.Net.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult) at System.Net.BrowserHttpWebRequest.<>c__DisplayClass5.b__4(Object sendState) at System.Net.AsyncHelper.<>c__DisplayClass2.b__0(Object sendState) --- End of inner exception stack trace --- at System.Net.AsyncHelper.BeginOnUI(SendOrPostCallback beginMethod, Object state) at System.Net.BrowserHttpWebRequest.EndGetResponse(IAsyncResult
asyncResult) at System.Net.WebClient.GetWebResponse(WebRequest request, IAsyncResult result) at System.Net.WebClient.OpenReadAsyncCallback(IAsyncResult result)}
L'errore viene scatenato alla chiamata del metodo ExecuteQueryAsync per l'esecuzione della query dall'applicazione client a SharePoint 2010. Ecco, è bene sapere che questo errore può accadere per due principali motivi: 1- L'indirizzo che avete inserito come parametro del costruttore principale della classe ClientContext non esiste, non funziona o non è raggiungibile tramite browser. 2- Non avete inserito alcun file di policy ("ClientAccessPolicy.xml") per regolamentare le connessioni ai web services di SharePoint dall'esterno, nella directory della vostra web application.
Come è possibile leggere dal punto 2, per consumare un web services (che sia o meno esposto da SharePoint) all'interno di un'applicazione Silverlight, è necessario che il web server che lo ospita abbia un file di policy che regolamenta la possibilità di utilizzo o meno del web service stesso da applicazioni remote. Questo file è il file "ClientAccessPolicy.xml", che e va creato all'interno della root della nostra applicazione web. Siccome il modello ad oggetti client-side ha, al suo interno, una classe proxy che si occupa di chiamare il servizio "Client.svc" esposto da SharePoint 2010 e leggerne le risposte, anche tutte le applicazioni che ne utilizzano i vari membri dovranno fare i conti con il medesimo modello di policy, in quanto pur scrivendo codice che mantiene il paradigma ad oggetti, alla fine vengono comunque fatte delle chiamate ad servizio web (in questo caso un servizio WCF). Per un introduzione sull'architettura del modello ad oggetti client-side di SharePoint 2010, trovate un articolo su SharePoint Community. Quindi, in ambiente di sviluppo, potete mettere un file nominato "ClientAccessPolicy.xml" all'interno della root della vostra web application SharePoint. Questo un'esempio classico:
<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="*">
<domain uri="*" />
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true" />
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
Prima di procedere, provate a raggiungere tale file tramite il browser in modo tale da essere sicuri che possa essere letto da tutti, utilizzando questo indirizzo:
http://[servername]/ClientAccessPolicy.xml
E poi fate un bel IISRESET.
Se siete in produzione invece, è meglio seguire le linee guida date da Microsoft per il posizionamento e la stesura del contenuto del file "ClientAccessPolicy.xml". Trovate invece più informazioni riguardo il modello di sicurezza per l'accesso a risorse esterne tramite applicazioni Silverlight qua: http://msdn.microsoft.com/en-us/library/cc645032(VS.95).aspx
Gestione di liste con il Client Object Model di SharePoint 2010
Continua la serie di articoli legati al Client Object Model di SharePoint 2010 pubblicati su SharePointCommunity. Dopo un articolo introduttivo e uno legato alle operazioni che possiamo fare su elementi di liste, questa è la volta delle classi e dei metodi per la gestione di liste presenti all'interno di siti SharePoint. Dalla creazione e
selezione di singole liste o gruppi di liste, alla modifica (nel caso specifico l'inserimento di un campo) e cancellazione. E' sicuramente un argomento molto interessante anche questo, perchè capita spesso di dover interagire direttamente con la struttura di una lista, a partire dalla sua creazione o dall'eventuale modifica di uno o più campi, da applicazioni client-side. Con il Client Object Model offerto da SharePoint 2010, non dobbiamo più utilizzare il web service "Lists" (come facevamo su MOSS 2007) e possiamo mantenere il paradigma ad oggetti durante lo sviluppo della nostra applicazione.
Questo il link diretto all'articolo: http://www.sharepointcommunity.it/articles/Lists/Articles/DispForm.aspx?ID=15
Se volete invece scaricare la soluzione Visual Studio 2010 che ho utilizzato per la stesura, la trovate qua: PeppeDotNet.SP2010.ListsManagement.zip
E se avete domande, potete scrivere direttamente sul forum Microsoft per lo sviluppo su SharePoint. Buona lettura ! :)
4. Workflow
Bug nell'utilizzo di una Delay activity in un workflow di SharePoint 2010 Dal forum italiano di sviluppo su SharePoint è venuta fuori un'interessante discussione sul mancato funzionamento di una Delay activity all'interno di un workflow sequenziale creato per essere eseguito all'interno di SharePoint 2010. Andando nei dettagli, a fronte di un'installazione standard di SharePoint, se si prova a sviluppare un workflow che utilizza una Listen activity con all'interno una Delay activity che blocca il worklfow per un numero preciso di minuti, vi accorgerete che il flusso di operazioni resterà fermo per sempre. Non ci sarà alcun modo per far ripartire quel workflow dopo aver aspettato i minuti definiti all'interno dell'attività di tipo Delay. Il workflow con cui io ho testato questo comportamento è rappresentato in figura.
Girando su internet ci siamo accorti che il problema era già presente all'interno della vecchia versione di SharePoint (WSS 3.0/MOSS 2007) e che non è stato corretto. C'è una soluzione però ! Per permettere il funzionamento di un workflow che utilizza una Delay activity è necessario settare una proprietà sul sito in cui si intende far girare il workflow, tramite l'utility STSADM. La proprietà in questione è la "", che va valorizzata con il valore: "". Quindi, prima possiamo provare a farci stampare il valore attuale della proprietà in questione:
stsadm -o getproperty -pn job-workflow -url http://siteurl
Poi, possiamo settarla:
stsadm -o setproperty -pn job-workflow -pv "Every 5 minutes between 0 and 59" -url http://siteurl
Una volta terminate le operazioni tramite l'utility STSADM, ricordatevi che è necessario un IISRESET e un riavvio del servizio timer di SharePoint.
Fatto questo, il servizio timer capisce che deve controllare i nostri workflow ogni 5 minuti e permette così alla Delay activity di scattare correttamente. Cosa molto importante da ricordare è che se vogliamo fare debug di un workflow di questo tipo, è necessario attaccarci al processo OSWTimer di SharePoint, altrimenti i nostri breakpoint non verranno mai catturati dal debugger.
Se volete metterci un pò le mani, ecco qua la soluzione di test che ho utilizzato per riscontrare effettivamente il bug sulla mia macchina: PeppeDotNet.DelayActivityBug.zip
5. Upgrade
Come avere un report esaustivo prima di una migrazione a SharePoint 2010 con il metodo "database attach"Una delle modalità più usate e più consigliate per effettuare una migrazione da MOSS 2007/WSS 3.0 a SharePoint 2010 è sicuramente quella dell'attach del database dei contenuti. Se avete mai provato questa modalità per le vostre migrazioni, saprete sicuramente come utilizzare il cmdlet "Test-SPContentDatabase" di powershell e saprete anche che il risultato prodotto da questa operazione risulta pieno di informazioni, forse un pò forvianti o pressoché inutili. Il tool infatti, visualizza sulla console le informazioni di base riguardo tutte le issue che potrete incontrare se decidete di migrare il vostro database dei contenuti alla nuova versione di SharePoint.
Sfortunatamente però, non otteniamo le informazioni che ci aiutano a capire quali sono queste issue e dove sono attualmente utilizzate. Per esempio:
Le feature che verranno perse durante la migrazione sono presentate solamente tramite il loro identificativo
Le web part che dovranno essere spostate/migrate, vengono presentate solamente tramite un'identificativo (ottenuto tramite il calcolo spiegato qua).
Questo significa che non siamo ne in grado di capire quali sono le web part che dobbiamo migrare, ne quali le feature e, sopratutto, non possiamo sapere dove queste sono attivate o utilizzate all'interno dei siti SharePoint presenti all'interno del database di contenuto che stiamo migrando. Questo rende decisamente difficile la nostra migrazione, sopratutto se ci troviamo di fronte ad un ambiente SharePoint 2007 che non abbiamo customizzato in prima persona.
Ecco quindi che, io e il mio gruppo, abbiamo sviluppato un piccolo tool di supporto a questa operazione che è in grado di leggere il report generato dal cmdlet "Test-SPContentDatabase" e generarne un secondo un pò più ricco diciamo. Infatti, una volta eseguito il nostro tool, una web part mancante che prima ci veniva presentata in questo modo:
And a MissingWebPart issue like
Category : MissingWebPart
Error : True
UpgradeBlocking : False
Message : WebPart class [xxx] is referenced [3] times in the database xxxx], but is not installed on the current farm...
nel nuovo report generato, verrà invece visualizzato quanto segue:
WebPart Details: CustomWebPart
WebPart name: CustomWebPart
WebPart Type name: CustomWebPart.namespace
Assembly Name: CustomWebPartAssembly, Version=1.1.0.0, Culture=neutral, PublicKeyToken=7668678dcd8080b491
WebPart Id:: xxx
This wep part can be located in the following pages:
SubSite/default.aspx
SubSite1/subsite/page.aspx
Quindi, dal niente a TUTTO ! :) Scherzi a parte, con questo tool siamo in grado di capire esattamente quali saranno le web part, le feature e le altre customizzazioni che dobbiamo migrare all'interno della nuova farm SharePoint 2010.
Per utilizzarlo, è necessario seguire questi passi:
1- effetture un backup e restore del database di contenuto all'interno del database server di SharePoint 2010 (qua per le istruzioni: http://msdn.microsoft.com/en-us/library/ms187048.aspx); 2- eseguire il comando "Test-SPContentDatabase" tramite powershell per generare il report di input (qua per le istruzioni: http://technet.microsoft.com/en-us/library/cc263026.aspx e http://technet.microsoft.com/en-us/library/ff607941.aspx); 3- Copiare il report generato all'interno della vecchia farm SharePoint 2007; 4- Eseguire il nostro tool passando il file .txt come unico parametro
Questa figura vi può chiarire il processo di utilizzo.
Per poterlo utilizzare, potete scaricare l'eseguibile compilato da codeplex o potete prendere i sorgenti e ricompilarlo. Ecco il link diretto al progetto: http://sp2010extmigrareport.codeplex.com/
Bene, mi sembra tutto :) Chiaramente il tool è ancora in fase di sviluppo e alcune missing customization non vengono recuperate nella loro interezza. Se qualcuno ha voglia di partecipare al progetto, ne saremmo ben contenti. Se invece, pensate di utilizzarlo per le vostre migrazioni e siete così gentili da darci un feedback, ne saremo sicuramente felicissimi !
TAGS: [SharePoint] [SharePoint 2010] [Upgrade] [Codeplex]Commenti(6) - Posted @ 9/27/2010 9:24:56 PM - Categoria: Sharepoint - Permalink - Share on twitter | facebook
COMMENTI
Autore: Gabriele - scritto il 1/5/2012 8:36:48 PM Fantastico... e adesso, come faccio ad istallare queste features in SP2010 ?
Autore: Peppe - scritto il 1/5/2012 8:45:58 PM
Ciao Gabriele. Una volta che hai individuato le feature, le web part e le site collection mancanti, devi cercare i sorgenti, migrarli a sharepoint 2010 ed installarli nella nuova farm. Se non hai i sorgenti, devi cercare di ricostruire quanto meno i file di definizione .xml (che trovi sotto il percorso /12) e tutti gli altri relativi file ad eccezione delle varie dll. Per le dll se sei fortunato ti funzionano senza neanche doverle ricompilare, altrimenti devi per forza avere i sorgenti.
Peppe
Autore: Gabriele - scritto il 1/6/2012 6:38:52 PM ho risolto, grazie a questa utilita' "magica", ho scoperto che tutte queste features non erano in uso, ma soltanto partecipanti ad un sotto-sito chiamato SandBox che fu creato diversi anni fa per test. L'ho rimosso, ne sono rimaste 3 "Powered by SharePointBoost" ed anche queste non sono in uso, le ho disattivate, adesso aspetto utenti, se qualcosa non funziona, le rimuovo, altrimenti le riattivo e le converto. Grazie mille, Gabriele.
Autore: Peppe - scritto il 1/6/2012 10:36:03 PM Bene, mi fa piacere. Figurati! Peppe
Autore: Gabriele - scritto il 1/10/2012 10:38:33 PM Ok, Sharepoint e' una bestia di prodottom pensavo fosse stao piu' facile ma mi ritrovo con dei problemi. Posso scriverti e chiederti un paio di consigli ?
Autore: Peppe - scritto il 1/10/2012 10:46:10 PM Ciao Gabriele, puoi contattarmi via mail quando preferisci. Trovi il mio indirizzo in fondo al sito. Altrimenti, puoi lasciare le tue domande sul forum microsoft:
http://social.msdn.microsoft.com/Forums/it-IT/sharepointitproit/threads
A presto Peppe
