Leggo con piacere sul blog di Brian Harry che si stanno muovendo un po' di cose relativamente all'Application Lifecycle Management applicato a soluzioni SharePoint.
Su MSDN è stata pubblicata una pagina di overview che si pone come punto di accesso per una serie di articoli a riguardo, tenendo presente che:
[...] SharePoint application development and practices can differ from Web and Windows-based development processes and procedures [...]
Mi spiace non aver potuto seguire la sessione di RoB alla SharePoint Conference, ma mi fa piacere constatare che l'argomento è "caldo" e che iniziano ad esserci guideline "ufficiali" :-)
Mamma mia quanta gente!
Venerdì scorso si è conclusa la Microsoft SharePoint Conference 2008 e il primo, più evidente parametro di successo dell'evento è la quantità di persone che hanno partecipato.
"Dire" quattrocento (arrotondato per difetto) fa una certa impressione, ma è un numero scritto.
"Sentire" quattrocento è un'altra cosa. E' stato quasi difficile muoversi tra una sessione e l'altra!
Tantissime domande, segno anche queste dell'interesse verso una piattaforma che, ormai, non ha più bisogno di presentazioni. Spero di essere riuscito a dedicare il tempo sufficiente a chi mi ha chiesto consigli o suggerimenti (una voce c'è stata per tutti, purtroppo in alcuni casi troppo sintetica per essere esaustiva... beh, dai, sapete dove scrivermi!).
Tantissimi commenti e considerazioni più "tecniche" da fare... ma proverò a dar seguito a questo post nei prossimi giorni.
Per ora, visto che la stanchezza si fa sentire, mi limito a ringraziare tutti (uno per uno :-P) perchè il successo di queste manifestazioni è fatto anche da chi partecipa in maniera entusiasta e dinamica, come è stato questa volta.
E infine grazie a Igor e a Paolo, che con Microsoft hanno reso possibile tutto questo. Perchè in fondo, pensateci un po', senza di loro ci si ritrovava in 400 a giocare a pallone al parco :D
E così si conclude la breve serie.
Anche in questo caso al plurale. E anche in questo caso l'aspetto che ho avuto modo di apprezzare maggiormente è la completezza che si può ragguingere quando si uniscono punti di vista differenti. L'altro pundo di vista è quello di Igor... e direi proprio che Igor non ha bisogno di presentazioni !!
In ogni caso, come sempre, ecco la descrizione di ALL305: STSADM.EXE without limits:
STSADM.EXE: chi non l'ha utilizzato almeno una volta non si può definire un esperto di SharePoint :-)
La console da riga di comando è veramente piena di risorse, che non si finiscono mai di scoprire.
Amministrare e configurare SharePoint da Command Prompt non è una mania per vecchi sistemisti, ma diventa una formidabile risorsa per realizzare automazioni e migliorare la qualità dei servizi offerti. STSADM.EXE può anche essere esteso nelle sue operations, aprendosi così verso nuovi potenti ambiti di utilizzo.
La sessione verrà erogata da un doppio punto di vista: quello dell'IT Pro e quello del Developer... chissà cosa combineranno sul palco! :-)
Parleremo di scipting - non potrebbe essere altrimenti - ma ne parleremo provando a focalizzare l'attenzione sugli scenarie e sulle modalità di estensione.
E vedrete che non serve imparare a memoria, uno per uno, quei 2 o 3 comandi (:-S) disponibili out-of-the-box!!
Quindi - e metto le mani avanti - non vi reciteremo a memoria l'output di stsadm -help :-P
L'altro giorno, durante la messa a punto delle slide, ci siamo trovati a chiederci: "Ma secondo te, STSADM cos'è?".
Per una risposta che vada al di là di "è un programma che serve ad amministrare SharePoint" è altamente consigliata la presenza qui :-P
Terzo e penultimo appuntamento con la mini-serie.
Questo è al plurale. E vi assicuro che il divertimento, durante la preparazione, è ben più che doppio :-)
L'altra metà del plurale è Elisabetta Sasselli. Vedendola lavorare, e soprattutto lavorandoci insieme, mi stava venendo voglia di disinstallare Visual Studio e tuffarmi un po' più spesso nei meandri di SharePoint Designer! E non lo faccio giusto perchè con CTRL-SHIFT-B mi apre il browser quando io, invece, continuo a chiederemi dov'è finita la mia dll :-P
Comunque, io e Betta giocheremo con le DataView - e il titolo la dice già lunga: SB302 DataView and XSLT: codeless revolution!
Ecco l'abstract:
Qualcuno vi ha detto che non è possibile personalizzare siti SharePoint senza utilizzare Visual Studio? Ci avete creduto?
Allora non avete sentito ancora parlare della codeless revolution :-)
In questa sessione Claudio ed Elisabetta spiegheranno come sia possibile intervenire sui siti SharePoint per ottenere velocemente risultati sorprendenti, pur non avendo conoscenze di linguaggi di programmazione. Esempi concreti e demo “dal vivo” mostreranno come, con una buona padronanza di SharePoint Designer e una discreta conoscenza di (X)HTML e XSLT, si possa arrivare in poco tempo e con poco sforzo alla costruzione di soluzioni articolate e accattivanti, in grado di estendere in maniera efficace le funzionalità out-of-the-box della piattaforma.
La sessione è ovviamente incentrata sulle DataView, dissezionate e ricostruite con l'intento di illustrarne il rationale-behind.
Il mondo dataview ha un fascino particolare, a mio modo di vedere.
Innanzitutto perchè la componente tecnica trova, più che in altre occasioni, un essenziale alleato nell'inventiva e nella "visione".
E poi perchè gli strumenti a disposizione (data source controls e trasformazioni XSLT, prevalentemente) sono assai flessibili.
Ruotano intorno al "dato", lo estraggono, lo elaborano e lo presentano. E garantiscono sempre al programmatore/site-builder un buon livello di astrazione, diretta conseguenza dell'approccio dichiarativo su cui si fondano.
Più che in altri casi, qui una demo vale più di mille parole.
Ma la demo, quella no, proprio non ve la voglio anticipare. Venite a vederla live :-)
Come detto, ecco qualche altra "voce di corridoio".
Giovedì mattina si parla (anche) di... ALL200: InfoPath and Forms Services: practical approach.
Cioè:
Si tratta di un "tutorial" che guida alla scoperta di Microsoft Office InfoPath 2007 e Microsoft Forms Services.
La sessione è rivolta anche a chi non conosce questi prodotti, ma vuole scoprirne il potenziale e iniziare a sfruttarli in soluzioni reali.
Tutta l'esposizione sarà incentrata sulla realizzazione di un caso di implementazione reale.
Sì, la descrizione è giusta :-)
E' una sessione dal taglio decisamente pratico e abbastanza introduttivo.
Credo (e spero !) che sia l'approccio corretto nei confronti di un prodotto, come InfoPath, che si riesce ad utilizzare con buoni risultati dopo un po' di "gioco".
Il che non significa che sia un tool giocattolo. Tutt'altro. Probabilmente è il modo con cui siamo abituati ad affrontare lo sviluppo di form che ci fa dire "oh, ma è così facile ?".
E vi anticipo una considerazione: "No, non è sempre così facile".
InfoPath ha il suo caratterino, che va conosciuto per essere in grado di domarlo all'occorrenza :-)
Però, una volta messi in evidenza certi limiti, è una soluzione che va assolutamente valutata nel momento in cui si devono realizzare applicazioni basate, in qualche modo, su form elettroniche.
Considerazione, quest'ultima, che è avvalorata in maniera particolare in seguito all'introduzione di Forms Services (il motore di rendering e di calcolo di IP ospitato lato server, in poche parole le form compilabili e inviabili direttamente dal browser).
Insomma, proveremo ad inquadrare tutti questi argomenti in un'ora e un quarto, amalgamandoli nel contesto di un esempio che ci seguirà dall'inizio alla fine della sessione.
Ci si vede là :-)
Inizio a dare qualche anticipazione (ma non troppe :-)) sulle sessioni che terrò alla Microsoft SharePoint Conference 2008.
Inauguro la serie parlandovi di ... DEV400: Custom Field Development in SharePoint.
La descrizione recita:
Tramite campi personalizzati è possibile estendere le funzionalità out-of-the-box di SharePoint, mantenendo omogeneità nei confronti dell'infrastruttura e del layout.
In questa sessione verranno dapprima illustrate le tecniche di base necessarie per lo sviluppo di custom field.
A seguire verranno proposte alcune implementazioni più avanzate, a dimostrazione della flessibilità e della potenzialità di questa feature.
Per la mia esperienza i custom field sono una caratteristica tutto sommato poco nota.
Ed è un vero peccato perchè, una volta affrontata una curva di apprendimento iniziale non sempre banale, sono uno strumento decisamente interessante, che consente di portare a termine estensioni mirate e, a volte, inattese :-)
Uno degli aspetti che li rende, a mio modo di vedere, maggiormente complessi è il numero di building-blocks che si devono mettere insieme per far funzionare il meccanismo.
Per questa ragione la sessione sarà incentrata sulla disamina puntuale di ciascuno di essi, nel contesto di un "pacchetto" che deve essere uniforme e, in qualche modo, adatto agli usi che ne possono derivare.
Parleremo (più o meno in questo ordine) di:
- Field Type Definition
- Field Type Class
- Field Properties
- Field Rendering Control
- Field Rendering Control Templates
- CAML Rendering (l'ho messo per ultimo se no fuggite tutti :-))
Sto completando le demo. L'idea è quella di corredare ciascun "angolo di visuale" con un esempio che ne dimostri uno scenario di applicazione, provando anche a confrontare approcci diversi, qualora disponibili.
Quindi ci si vede là !
p.s. Approfitto per ricordare che oggi scade l'early-bird, che consente di risparmiare 60 euro sulla tariffa di iscrizione :-)
... e in un titolo assurdo si trovano sintetizzate tre cose speciali !
La collaborazione.
Il sottotitolo può essere "Dev e Site Builder, una miscela esplosiva" (e se volete vedere non una ma due esplosioni :-)).
Oppure, se vogliamo allargare il discorso al di fuori dello sconfinato mondo SharePoint, ci sta bene anche "Sviluppatore e Sistemista non sono come cane e gatto".
Quella che si tende a fare, in questi casi, è spesso una "suddivisione".
E, a volte, è una suddivisione necessaria. Pensate alla formazione, ad esempio, settore in cui è forte la necessità di categorizzare gli argomenti per offrirne una differenziazione basata sulle competenze (a livello di prerequisiti così come di obiettivi).
Però, se possiamo mettere in secondo piano l'aspetto delle conoscenze puramente tecniche, lo scenario cambia :-)
Il tuttologo, ad oggi per lo meno, non ha più senso di esistere. Troppe cose, troppo complesse, troppo ampie per essere conosciute in maniera approfondita.
Triste ? Realistico ?
Perchè mai ! In fondo "non sapere fare" è molto, molto diverso da "non sapere che esiste" o "non sapere a chi chiedere".
Io rientro nella categoria dev. So fare le "mie" cose (almeno sulla carta :-D). Me la cavo quando si parla di argomenti "itpro", me la cavo pure quando si parla di argomenti "da sitebuilder". Ma non ho quel "di più" per tirarmi fuori dagli inghippi di una infrastruttura di rete anomala o di una master page troppo particolare. Mi manca la "scintilla".
I progetti che si realizzano (e le demo sono uno di questi) non hanno nozione diretta di questa categorizzazione dei ruoli, ed è giusto che sia così, perchè nel risultato finale le tecniche e gli approcci si devono fondere in una soluzione fluida e omogenea, a prescindere dalla modalità con cui essa viene realizzata.
Questa omogeneità non può essere raggiunta (quasi mai, almeno) se viene meno una visione globale delle esigenze e dei requisiti. E questo non solo in fase di implementazione (dove forse è tardi) ma soprattutto durante la progettazione del sistema.
Ed ecco che le capacità non si misurano più con le competenze nel proprio settore, ma con la capacità di inquadrarle in un contesto più generale.
Un dev che sa "vedere" con gli occhi di un site builder rimane a contatto con la piattaforma che usa, dimenticandosi ogni tanto che "intanto via codice si può fare tutto" e, forse, riuscendo a non reinventare ciò che esiste e che, suo malgrado, è stato fatto meglio.
In questo faccio una critica che è anche autocritica. Ma con un'apertura che ritengo fondamentale e che è, in fondo, l'amalgama per il titolo di questo post.
Perchè una miscela è fatta di ingredienti.
Consentitemi una metafora gastronomica direttamente della mia terra.
Il pesto.
Il pesto si fa tra le altre cose con il basilico e l'olio.
Provate a preparare questa prelibatezza con un olio di bassa qualità e ... il pesto non viene un granchè :-(
Ovviamente, perchè le "competenze" servono e non sono prescindibili.
Dopo, però, provate a fare il pesto senza olio. Metteteci pure il basilico più buono di questo mondo. Viene bene ? Può darsi. Ma non è pesto !!
Nel pesto, probabilmente, la componente basilico è predominante. Questo è normale, anche perchè il bilanciamento in una ricetta non è dato da una divisione in parti uguali tra gli ingredienti.
Ed ecco che l'arte del bravo cuoco sta nel ricercare gli ingredienti giusti e nel saperli miscelare in proporzioni e in tempi opportuni.
In fin dei conti, parlo di cucina ma intendo, più in generale, la collaborazione di cui sopra.
Ed è curioso perchè ne sto parlando nel contesto di una piattaforma, SharePoint, che viene venduta ed è a tutti gli effetti collaborativa per definizione (il nome vorrà pur dire qualcosa, no ?)
Progettiamo soluzioni collaborative. Questo ci viene richiesto, in maniera più o meno diretta. Questo si prova a fare, in maniera più o meno efficace.
E ... Ah sì, un'altra cosa (last but not least, come si dice).
Le cose verdi.
Il pesto ha un colore verde intenso, brilla quasi.
Non credo di avere un colore preferito, come viene chiesto nei quiz sui giornali o nelle domande stile "se hai dimenticato la password, rispondi a questa".
Però adoro il verde del pesto (in realtà adoro la terra che lo produce).
E c'è un'altra "cosa verde" che mi piace un sacco, che è il gruppo in cui sono piombato a pesce dopo 4 anni di vita da libero professionista.
Il pesto mi sa che dovrò introdurlo io, perchè a in quella zona lì non si sa mai cosa mangiare (dopo che uno ha provato 84 tipi di tortellini e di ragù, le lasagne, la gramigna, la salama (aargh), la piadina, i gnocchi fritti, le crescentine e qui mi fermo perchè non vorrei far torto a nessun piatto tipico).
L'ambiente collaborativo è invece una delle tante cose belle che trovo.
E al quale spero di poter dare il mio contributo :-)
E' stata rilasciata da pochi giorni la September 2008 CTP di F#, il linguaggio funzionale che (e questa release ne è la prova) andrà ad aggiungersi alla suite di linguaggi supportata in maniera nativa da Visual Studio.
Don Syme, leader del progetto F#, linka qui la pagina di download aggiornata (sono state pubblicate alcune fix immediatamente dopo il rilascio della CTP).
Su MSDN è inoltre disponibile il F# Developer Center !
Questo il post con l'annuncio di Somasegar.
Se vi chiedessero di nominare 5 libri di informatica che avete letto e che hanno avuto un contributo significativo per la vostra cultura e per la vostra crescita professionale, quali nominereste ?
Domanda banale ? Domanda troppo complicata ?
Forse sì, anche perchè il confronto può risultare arduo quando si vanno a considerare testi che differiscono non solo per contenuti, ma anche per approccio o, magari, per stile.
Un libro che non posso togliere dalla mia classifica, ad esempio, è il primo che ho letto integralmente, del quale non ricordo nè autore nè casa editrice (sigh ...) ma solo il colore della copertina (rosso acceso) e l'argomento (una sorta di guida di livello intermedio sui PC e sul loro funzionamento).
[Non se ne trovano più in giro. Non so se è una sensazione solo mia, e magari errata, ma adesso la tendenza sembra premiare il "tutorial-che-ti-insegna-a-programmare-in-6-lezioni-da-un'ora" :-(]
Don Box trova posto come autore (così ne occupa solo uno :-P ... insomma, se vinci non puoi anche arrivare secondo). La Addison-Wesley, spannometricamente parlando, come casa editrice.
E poi c'è questo volumetto da 300 pagine o poco più, edito da O'Reilly, acquistato più per curiosità che per reale interesse (almeno all'epoca) ed entrato in top five a velocità sorprendente.
Shared Source CLI Essentials è un viaggio negli gli internals della "macchina virtuale" .NET.
E' un libro che ti fa venire voglia di prendere in mano un debugger e di fare le pulci a quel runtime che ospita le tue applicazioni di tutti i giorni.
E' un libro che riprenderei in mano volentieri, ad avere anche solo un pochino di tempo.
Ecco perchè sono davvero contento di leggere, da Joel Pobar e da Ted Neward, che è disponibile una bozza della versione 2 del succitato volume, arricchito da:
Updated to reflect the 2.0 source code. A *lot* of stuff changed internally, specifically for deeply engrained type system features like Generics. Added a chapter on Reflection and Code Generation features. We talk about new 2.0 features like Lightweight Code Generation (LCG) and the new Reflection caching mechanisms. Added a chapter on Generics to explore how it works under the hood, from metadata changes, right through to runtime data structure changes. Added an Appendix tutorial that walks through step-by-step the changes required to add a new opcode to the runtime (everything from verification, to JIT compilation). Explores a new interface call dispatch architecture called “Virtual Stub Dispatch”. Looks at the new native x86 calling convention.
Un must, come si dice. Davvero !!
I Microsoft Office Labs hanno reso disponibile pptPlex, un add-on per PowerPoint che ... dà vita alle presentazioni aggiungendo effetti di zoom e pan durante la navigazione tra le slide (e all'interno della stessa slide, quando i contenuti sono troppo minuscoli).
pptPlex is a plug-in that explores an alternate method for presenting a PowerPoint slide deck. Using pptPlex, you can present your slides as a tour through a zoomable canvas instead of a series of linear slides
Le parole si spiegano molto peggio di un video :-)
L'ho installato e provato per qualche minuto e devo dire che è estremamente interessate, e non solo per via degli effetti.
Offre una modalità di navigazione (e quindi di presentazione) che ben si presta all'esposizione di contenuti non sequenziali, per la quale un ritorno ad una schermata di overview interattiva è utile didatticamente, oltre che molto ad effetto.
Utilizzare questo add-on "in produzione" forse è prematuro:
Q. Can I run my business with these tools?
A. These prototypes are unsupported so we don't think that would be a good idea.
Speriamo quindi in un buon supporto e, magari, in una integrazione nella prossima versione di Office :-)
Oggi mi sono appollaiato sotto il sole dell'alta Toscana con l'intenzione di preparare un po' di materiale per la SharePoint Conference di ottobre.
Ho riorganizzato un po' di esempi, completato qualche snippet di codice lasciato da un po' di tempo nei "todo" di outlook e poi mi sono dedicato al packaging per la sessione su STSADM che terrò con Igor.
Ovviamente non svelo nulla (:-P) ma, giacchè sono tuttora appollaiato sotto la luna dell'alta Toscana, vi scrivo un piccolo tip.
L'esigenza è stata quella di creare una solution SharePoint in grado di effettuare il deploy di una custom stsadm extension. Il che si riduce, per farla breve, alla distribuzione di un assembly in GAC (e sin qui nessun problema) e alla copia di un file in [12]\CONFIG.
Il meccanismo di packaging in solutions consente entrambe queste operazioni (definendo i relativi elementi Assembly e RootFile nel manifest della solution, e ovviamente includendo i file nel pacchetto generato):
<Solution ... >
<RootFiles>
<RootFile Location="CONFIG\stsadmcommands.Spc2008.xml" />
</RootFiles>
<Assemblies>
<Assembly Location="Spc2008.StsAdmExtensions.dll" DeploymentTarget="GlobalAssemblyCache" />
</Assemblies>
</Solution>
Purtroppo, però, STSDEV non è in grado di inserire file nella directory CONFIG.
Ponendo come presupposto che:
- Tutte le mie altre demo sono basate su progetti creati con STSDEV ... e vorrei mantenere un minimo di omogeneità almeno con me stesso :-)
- STSDEV è un tool eccellente, sia per funzionalità che per facilità di estensione
- STSDEV è corredato da codice sorgente
tutto sommato l'idea di metter su una patch non è così tanto campata per aria.
Step by step, la patch è costituita da:
1) In Globals.cs, definizione di un nuovo campo String all'interno della classe stsdev.Globals, inizializzato con il percorso della directory CONFIG:
public readonly static string ConfigFolder = RootFilesFolder + @"\CONFIG";
2) In CabDdfBuilder.cs, modifica del processo di generazione del file DDF (alla base della successiva creazione del pacchetto WSP), rilassando il controllo sull'esistenza delle directory nel ramo di progetto per includere anche RootFiles\Config:
if (Directory.Exists(Globals.IsapiFolder) || Directory.Exists(Globals.ResourcesFolder) || Directory.Exists(Globals.ConfigFolder))
3) In ManifestBuilder.cs, modifica del processo di generazione del manifest della solution, rilassando il controllo sull'esistenza delle directory nel ramo di progetto per includere anche RootFiles\Config:
if (Directory.Exists(Globals.IsapiFolder) || Directory.Exists(Globals.ResourcesFolder) || Directory.Exists(Globals.ConfigFolder))
Rebuild, test e via :-)
Ah, per inciso.
L'avete visto, no, che Ted Pattison (creatore - tra l'altro - di STSDEV) terrà una sessione proprio sulla sua creatura ?
Paul Andrew annuncia che è disponibile su Codeplex una "not-even-alpha version" della SharePoint Guidance.
La descrizione schematica che troviamo in home è piuttosto precisa:
Project Description
We plan to provide guidance to customers on how to build SharePoint Intranet Applications. This includes guidance on how to Architect, Design, and Develop applications as well as best practices.
Intended Audience
This guidance is intended for software architects and software developers who are building applications on Microsoft Office SharePoint Server. Familiarity with Windows SharePoint Services, Microsoft Office SharePoint Server, and ASP.NET is useful for evaluating the guidance.
Guidance is not even Alpha
Please note that this guidance is in draft form and will change dramatically before it is released on MSDN. We provide you access to drops to give you an idea of our direction and get your feedback. The code will continually be refactored until the point we publish it on MSDN.
Evidentemente ... "they heard from customers" (cit.) :-)
Non aspettatevi di trovare nulla di lontanamente definitivo ... però, visto che curiosare è in fondo lecito e, a dire il vero, richiesto, diamo un'occhiata partendo dalla "vision" di questa drop. Mi sono permesso un ritaglio dal pdf:
Interessante il ranking delle richieste più gettonate.
Il Debugging sembra avere la meglio su altre "piccole" questioni quali tooling (VSeWSS vs STSDEV vs WSPBuilder vs SmartTemplates vs Custom Batch vs Tutto A Mano ...) o Sviluppo in Team (che secondo me è invece il punto più interessante e aperto, e se volete va giù a domino coprendo la maggior parte degli altri desiderata).
Interessante soprattutto il fatto che alcune esigenze, che personalmente giudico *primarie* per *qualsiasi* ambiente di sviluppo, siano presentate in un documento di Vision come must have, e quindi sia lecito aspettarsi una risposta "ufficiale" (da seguire o non seguire a discrezione, ci mancherebbe, ma sempre utile come termine di confronto).
Mi riferisco in particolare al SDLC (Software Development Life Cycle) e a quanto/come/quando di questa disciplina si possa/debba applicare alle soluzioni SharePoint.
In termini più pratici, e solo per fare un esempio, tutti sappiamo che si devono fare i test, semmai il punto è individuare la metodologia più corretta per farlo, tenendo ovviamente in conto l'ambiente target, i suoi vincoli e le sue particolarità.
Alla SharePoint Conference avremo sicuramente occasione di discutere anche di queste cose. Io ho già pronta qualche domandina per Ted Pattison ... preparate le vostre :-)
Segnalo questo post di Rob Nowik che propone una soluzione, semplice ed efficace, per modificare le property di una web part al di fuori del "classico" tool pane.
Questo approccio può risultare assai utile, ad esempio, quando le proprietà che si vogliono gestire richiedono un cruscotto grafico particolarmente oneroso in termini di spazio sulla pagina, tanto da rendere insufficiente - o comunque troppo esiguo - il pannello laterale.
Da qualche tempo sono stati pubblicati due "poster" che illustrano graficamente le operazioni e le proprietà disponibili per la gestione di un'infrastruttura SharePoint via STSADM.
Per WSS: jpg, png, Visio
Per MOSS: jpg, png, Visio
Molto bene, così alla Microsoft SharePoint Conference 2008 io e Igor ve li mostreremo *tutti* :-O
Sono capitato un po' per caso a leggere questo post su Bamboo Nations (che, devo dire, sta scalando rapidamente la mia feed-parade).
Riporto qui un brevissimo e significativo excerpt:
[Deploying SharePoint Solutions]
So if you decide to put anything into the GAC make sure it's NOT shared by anyone else since then it will break if you retract one of the solutions....
Dunque, un minimo di spiegazione !
Il meccanismo di deploy delle solution SharePoint consente di installare, come parte del package, assembly nella Global Assembly Cache.
In questo senso (e in realtà non solo in questo senso, estendendo il discorso ad altri tipi di risorse o di location di installazione) le solution possono essere definite senza troppo margine di interpretazione "l'MSI di SharePoint".
Con le funzionalità aggiuntive che la piattaforma richiede (allineamento garantito tra i server della farm, per dirne una). Ma, anche, con qualche funzionalità in meno.
Si parlava di GAC.
La GAC è utilizzata (e pensata) come storage per assembly condivisi fra più applicazioni. Quando più applicazioni tentano di installare un assembly in GAC, possono richiedere la memorizzazione di riferimenti (si chiamano trace references) in modo tale da evitare disinstallazioni forzose e conseguenti, brutali crash.
Ho scritto possono ... perchè ovviamente ci sono le eccezioni.
Una di queste (purtroppo) è appunto il meccanismo di deploy delle solutions.
Prova del nove (seguire passo passo - uso le VSeWSS Extensions per rapidità, benissimo qualsiasi altro tool o il tutto a manina).
1) Creare un progetto class library, anche vuoto va benissimo (purchè compili !). Nell'esempio l'ho chiamato SomeSharedAssembly.
2) Firmare l'assembly (il metodo più comodo è dalle proprietà del progetto Visual Studio, voce Signing).
3) Build.
4) Creare uno SharePoint Empty Project (SolutionOne).
5) Add->Existing Item->La dll creata al punto 3.
6) Modificare il file manifest dela solution. Se avete usato le VSeWSS potete utilizzare il pane "WSP View", doppio click su manifest.xml. Ottenete qualcosa del genere (in bold la riga da aggiungere, ovviamente cambiando il nome della DLL creata al punto 3):
<?xml version="1.0" encoding="utf-8"?>
<Solution
SolutionId="961c3359-9b2b-4c29-86ed-b1a6399de968"
xmlns="http://schemas.microsoft.com/sharepoint/">
<Assemblies>
<Assembly Location="SolutionOne.dll" DeploymentTarget="GlobalAssemblyCache" />
<Assembly Location="SomeSharedAssembly.dll" DeploymentTarget="GlobalAssemblyCache" />
</Assemblies>
</Solution>
7) Build e deploy della solution.
8) Ripetere i punti 4..7, creando una solution identica con nome diverso (SolutionTwo, diciamo).
9) Ci troviamo con due solution installate e deployate (ripeto, se avete usato altri tool o avete scelto la strada "raw", alcuni dei punti precedenti possono cambiare, in particolar modo la creazione del package WSP e la sua successiva installazione).
10) Command prompt di Visual Studio (giusto per avere impostate le variabili d'ambiente) e lanciamo gacutil.exe (credo che gacutil non abbia bisogno di presentazioni, è *il* tool usato per esaminare ed interagire con la GAC via linea di comando).
11) gacutil -l SomeSharedAssembly. L'output dovrebbe indicare che è presente l'assembly richiesto:
D:\Windows\system32>gacutil -l SomeSharedAssembly
Microsoft (R) .NET Global Assembly Cache Utility. Version 3.5.21022.8
Copyright (c) Microsoft Corporation. All rights reserved.
The Global Assembly Cache contains the following assemblies:
SomeSharedAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=38b02c7e6
914e65f, processorArchitecture=MSIL
Number of items = 1
12) stsadm -o retractsolution -name solutionone.wsp -immediate (controllate di avere stsadm nel path, altrimenti lo dovete invocare con il suo percorso completo, [12]\bin)
13) stsadm -o execadmsvcjobs (se non volete aspettare nemmeno quei pochi secondi affinchè il timer job che effettua il retract (= undeploy) della solution venga eseguito
14) Di nuovo gacutil -l SomeSharedAssembly.
15) Osservare e riflettere ...
Microsoft (R) .NET Global Assembly Cache Utility. Version 3.5.21022.8
Copyright (c) Microsoft Corporation. All rights reserved.
The Global Assembly Cache contains the following assemblies:
Number of items = 0
Abbiamo due solution che utilizzano lo stesso assembly condiviso. Facendo il retract di una delle due (a caso) abbiamo disinstallato l'assembly dalla GAC ... lasciando l'altra in braghe di tela :-O
More Posts
Next page »