I pro e i contro dei VSTO (con note per chi inizia)

I pro e i contro dei VSTO (con note per chi inizia)

Quel che segue è un carteggio tra me e il nostro beneamato Webmaster, ossia Fulvio Giaccari, probabilmente uno dei massimi esperti dei VSTO (Visual Studio Tools per Office), nonché sviluppatore esperto di Visual Studio 2005. In particolare merita una segnalazione il fatto che l’ultima edizione del package verticale della sua Azienda (dedicato ai negozi di ottica) supporti un’interfaccia del tipo Ribbon (il nastrone di Office 2007!). Io invece provengo dal più umile mondo VBA (Visual Basic Application Edition), per cui nutro dubbi e timori dettati magari da pregiudizi e... pigrizia.

Ciao Fulvio,

In sintesi, ecco i pro e i contro dei VSTO , secondo me.

PRO

1)     Ottima integrazione col VB .NET e VB 2005;

2)     possibilità di usare C# oltre che Visual Basic;

3)     moltissime migliorie rispetto alle normali macro VBA;

4)     tentativo di coinvolgere maggiormente i professionisti edp, finora più che riluttanti verso Office e VBA;

5)     le applicazioni create sono “garantite” (trusted), per cui il loro deployment interaziendale avviene nella massima security possibile (ma sarà del tutto al riparo dagli attacchi degli hacker più diabolici?).

CONTRO

1)     Il VBA non è defunto e Microsoft non ha certo nessuna intenzione di cessarne il supporto;

2)     non escluderei che le migliorie di cui al p. 3 dei PRO non vengano introdotte anche nel VBA di Office (ma non sembra che ciò sia avvenuto con Office 2007);

3)     tali migliorie, comunque, non sono essenziali, e sicuramente in massima parte possono essere ottenute con “classico” codice VBA; forse sbaglio, ma oso dire che con un po’ di ingegno molto sia possibile pure in ambito interaziendale, usando sinergicamente i vari membri di Office, tramite Outlook, Infopath e, naturalmente, OLE Automation;

4)     accresciuta complessità concettuale e sintattica; a onta delle tecniche di “scorciatoia” di tutti i babbi, nonni e… antenati, coi VSTO il male non troppo oscuro della verbosità della programmazione object-oriented assurge a vertici impressionanti e, oso dire, scoraggianti (ma la pratica ha poi ridimensionato questo timore, v. più avanti);

5)     tale complessità e la necessità di apprendere, perlomeno, i fondamenti del VB .NET taglia fuori la maggioranza degli sviluppatori anche esperti VBA (i cosiddetti power user);

6)     la necessità di acquistare il package VB .NET o 2005 taglia fuori quasi del tutto gli sviluppatori VBA indipendenti, ossia il largo pubblico dei power user;

7)     per contro dubito che i professionisti VB .NET si convertano ai VSTO… (esempio emblematico: Francesco Balena, guru, direi, mondiale del VB .NET non ne fa menzione nella sua enorme bibbia);

8)     forse sbaglio, ma la security di cui al p. 5 – che NON serve alle necessità del singolo utente isolato - ha come contropartita serie difficoltà nel deployment, specie verso il largo pubblico (*) che temo possa scoraggiare i power user anche di fascia alta. D’altro canto, nel mio blog credo di aver indicato tecniche semplici atte a garantire un buon grado di security, ancorché imperfetto…

Pronto a cambiare, almeno in parte, idea non appena avrò modo e tempo per vedere meglio da vicino i VSTO, ma per tutte queste osservazioni ho motivo di ritenere non solo che i VSTO sono destinati ad una fetta del mercato (come d’altronde rientra nelle intenzioni ufficiali di Microsoft) ma che il target effettivo non possa essere troppo elevato.

Ciao Gianni,

sono sicuro che VBA non viene sostituito da VSTO! L’ho detto anche in alcuni miei interventi (mi sa che proprio durante l’evento SMAU).

Il deployment è uno delle problematiche più importanti di VSTO, ma una volta imparato è relativamente semplice distribuirli anche attraverso i libri. Io per esempio ho generato un file di setup che da ai miei assembly (realizzati con strong name)  le proprietà “Full Trust” su tutta la macchina!

Penso che Balena non ne parli anche perché è troppo nuova come tecnologia, i passi fatti dalla 2003 alla 2005 sono stati notevoli e soprattutto sostanziali … basti vedere che l’IDE di Word ed Excel sono stati incorporati all’interno di VS 2005.

La possibilità di utilizzare come front-end per le proprie applicazioni Office (e soprattutto come client di applicazioni create con sistemi anche web) è una prospettiva molto allettante ….

Che il mercato ancora è acerbo, sono convinto anche io. Ma il numero crescente di sviluppatori che mi scrivono, che visitano il sito (circa 1000 al giorno) mi dicono che il mercato è in crescita esponenziale. Siamo noi che dobbiamo cercare di spiegare tutti i benefici agli altri sviluppatori (altrimenti a cosa serviamo???)

In molti punti sono d’accordo con te … in altri un po’ meno.

Ti saluto, per ora

Ciao Fulvio,

ho chiarito diverse questioni e, soprattutto dubbi, così penso di scrivere appena possibile un articolo su questo tema, rivolto prevalentemente ai power user. Prima vorrei sottoporre alla tua attenzione un punto importante, su cui hai dato assicurazione ma che sarebbe utile venisse da te chiarito, come si suol dire, all’inclita e al volgo:

Come si compie concretamente il deployment di un modello implementato coi VSTO?

Il punto da cui parto è che, per default, non sembre consentita nemmeno la copia della cartella contenitrice in un altro disco o directory. Immagino che le manovre per ovviare ci siano e che siano note ai programmatori VB .NET o 2005. Giusto? Ma perché non far sapere al contadino (power user) quant’e’ buono il formaggio con le pere? Infatti è ovvio che i power user difficilmente riescono a spupazzarsi il malloppone VB .NE / 2005, d’altro canto se costoro sono tagliati fuori sicuramente la diffusione “di massa” dei VSTO verrà seriamente pregiudicata, non trovi?

Fulvio svela come si fa il deployment!

Ciao Gianni,

Il deployment, in effetti, non è semplicissimo. Dopo vari tentativi (anche perchè non c’è niente di scritto a tal proposito) sono riuscito a capire come funziona.

Partiamo dall’inizio.

Con l’avvento di Windows Vista sarà sempre obbligatorio certificare non solo le applicazioni ma anche gli assembly (quindi le DLL) se gli sviluppatori vorranno sviluppare ancora delle applicazioni . Alla luce di questa rivoluzione sulla security apportata dalla software house di Redmond l’unico scenario che vedo possibile è il seguente.

1. Per prima cosa certifichiamo l’assembly generato da Visual Studio durante la fase di Build  con il programma signcode.exe (lo si può scaricare gratuitamente dal sito MSDN).
2. Una volta certificato l’assembly entriamo nell’applicazione CAS (Code Access Security) del framework 2.0, mediante Start > Pannello di Controllo > Strumenti di amministrazione > Microsoft .NET configuration 2.0.
3. Espandiamo la voce My Computer ed entriamo nella cartella Runtime Secvurity Policy, ove sono presenti tre voci, per ognuna delle quali dobbiamo caricare una policy relativa a tutte le applicazioni certificate con il nostro certificato digitale.
4. Espandiamo la voce Enterprise (la prima dell’elenco), espandiamo la cartella All_Code e facciamo clic su quest’ultima col tasto destro del mouse.
5. Selezioniamo la voce “New” e compiliamo tutti i campi:

- nel campo Name inseriamo il nome della policy;

- nel campo Description inseriamo tutto quello che vogliamo, anche nulla.

6. Premiamo il pulsante Next. In questa sezione dobbiamo scegliere il tipo di regola che vogliamo scegliere. Dal menu a tendina cominciamo con lo scegliere la voce Publisher.
7. Premiamo il pulsante Import from signed file e selezioniamo il file appena firmato.
8. Diamo un clic su Next, poi selezioniamo come permessi Full Trust (dovrebbe essere già selezionato).
9. Ancora clic  su Next,  poi  su Finish.
10. Ripetiamo i passi precedenti anche per le voci Machine e User.

Adesso dobbiamo create i file .msi che andranno ad installare le policy sulla macchina del cliente (inoltre con questi MSI potremmo creare delle regole di bootstrapping per il setup con Visual Studio 2005 delle applicazioni di qualsiasi tipo).

11. Per creare il file .msi diamo un clic destro sulla cartella Runtime Security Policy” e selezioniamo la voce Create Deployment Packag” e creiamo un pacchetto per ogni singola voce (Enterprise, Machine e User).

Altri dubbi, in parte fugati (carteggio con Microsoft USA)

Come anticipato sopra ho in seguito avuto scambi e-mail con un paio di Evangelist di Redmond, un certo (gentilissimo) Andrew soprattutto. Sintetizzo i dubbi da me espressi, unitamente ai chiarimenti di Andrew.

Funzioni d’utente Excel

In gergo UDF (User Defined Function). Si tratta di funzioni personalizzate che possano anche essere liberamente usate sul foglio di lavoro dallo stesso utente finale. Fino a un aggiornamento dei VSTO (che, onestamente, ancora non possiedo) non si possono creare coi VSTO.

Ammette Andrew: “Right now, VSTO does not support automation add-ins (the standard way to build managed UDFs). The only way to achieve this is to hook up your functions via proxies in VBA.” In parole povere, si può sempre ricorrere al buon vecchio VBA per queste cose.

Macro associate a forme, immagini ecc. (poco da fare)

incorporate sul foglio, e/o a controlli classici di Excel (quelli della barra strumenti “Moduli”. Sul dubbio da me espresso, Andrew non si è pronunciato per quel che riguarda forme & C., mentre sui controlli classici sostiene che “You can get to any of the classical controls using FindControl. You can also get to any commandbar controls using FindControl.” Al momento non sono riuscito a seguire il consiglio, che giro a chi ha più tempo (e bravura).

E per gli altri oggetti? Dopo altre prove posso affermare, senza ombra di dubbio, che la cosa è impossibile. Per fissare le idee, si immagini di aver incollato sul foglio di lavoro un oggetto qualsiasi attinto dalla barra strumenti Disegno (forma, clipArt, WordArt e quant’altro).

Ø      Tanto per cominciare, è del tutto inutile dare su di esso un clic destro: l’opzione Assegna macro..., familiare in Excel + VBA brilla per la sua assenza nell’IDE VSTO.

Ø      Avendo in seguito scoperto, in modulo quale Foglio1.Vb, la presenza di oggetti anche inediti come i NamedRange dotati di vari eventi e relative routine, mi sono chiesto se per caso non fossero trattati in questo modo anche i sospirati oggetti embedded. In altri termini, la speranza era di trovare routine pre-definite del tipo Private Sub TexBox1_Click (.....) / End Sub. Niente da fare, speranza vana, eccezion fatta per i grafici incorporati.

La scoperta dei NamedRange con eventi, nonché di eventi nuovi come StartUp e ShutDown relativi a singoli fogli di lavoro è degna di menzione e interessante. Ne ho fatto materia per un articolo specifico, su questo sito:

http://blog.shareoffice.it/giannigiaccaglini/articles/8920.aspx

E i grafici incorporati? Sono gli unici oggetti dotati di specifici eventi. È una novità  senz’altro meritevole di essere approfondita. Al momento rivelo una personale delusione, nata dall’idea di poter lanciare una macro (qualsiasi, intendo) attivando in qualche modo un grafico del genere. Sia esso un tal Chart_1. In assenza di un evento Click ho cercato (ingenuamente?) di surrogarlo con l’evento Activate, l’unico che mi è parso consono. Così ho tentato la routine seguente:

Private Sub Chart_1_ActivateEvent() Handles Chart_1.ActivateEvent

  MessageBox.Show("Sono Un grafico, non vedi?")

  Chart_1.Deselect()

  With (Application.ActiveCell)

      .Select()

      .Value = "Sono un grafico!"

  End With

End Sub

Ebbene il Debugger non fa una piega, ma non c’è verso di ottenere null’altro che l’idiota massaggino. Tutte le volte l’attivazione del grafico evidenzia i contorni colorati della serie dati sul foglio ma ignora del tutto le istruzioni relative alla cella attiva. Neanche Chart_1.Deselect(), estremo tentativo di de-selezionare il grafico ha effetto. Superfluo dire che, invece, in VBA la macro associata a un grafico incollato esegue regolarmente le istruzioni relative alla cella attiva.

Lentezza delle soluzioni VSTO

È una cosa che salta all’occhio in tutte le prove: i VSTO sono più lenti rispetto alle macro VBA. Andrew lo ammette e spiega che “The price you’re paying here is the price for loading the CLR (Common Language Runtime) into the process. This is unavoidable – you have to load the CLR, no way round that. Don’t forget that when you open an Office app, you’re already paying the price of loading the VBA runtime. You only pay for the CLR if you have managed code in the process. You always pay for VBA.”

Traduzione spicciola: i pur brillanti VSTO richiedono sia il runtime di VB .NET o 2005 che quello dei VBA. Approfondendo il discorso su un buon libro USA sui VSTO ho appreso che non è tanto la compresenza a creare lentezza ma il fatto che il codice VSTO deve il più delle volte chiamare il VBA in soccorso, mentre le macro tradizionali lo invocano direttamente.

Di riflesso va fatta una... riflessione ( per l’appunto) anzi due:

• se si disattiva il VBA i VSTO non funzionano proprio (anche se quel tal MioFoglio.xls o MioDocum.doc non incorpora nessuna macro VBA);
• la security delle soluzioni VSTO è, più correttamente, una questione di tipo “trusted”, inoltre va sfatata la leggenda che esse lavorerebbero anche su PC di utenti con le macro VBA disabilitate (per contrastare i virus da macro).

Note conclusive, provvisorie

Dalla precedente corrispondenza e da altre esperienze deduco altri PRO e CONTRO. Comincio dai secondi, per non apparire uno stroncatore dei VSTO che invece hanno potenzialità notevolissime.

CONTRO

• I VSTO richiedono il possesso del package VB .NET o 2005. E c’è il dubbio che questo implichi licenze anche nella distribuzione dei modelli VSTO realizzati. O no?
• La sintassi è sicuramente più razionale ed evoluta ma, insieme, più complessa. In particolare le costanti “figurate” sono lunghissime (molto più, ad es. di una xlEnableCancelKey, cui nei VSTO corrisponde…. controllate voi stessi). A volte occorre specificare l’intero percorso dell’oggetto-padre (Excel, Word ecc., seguiti da “.Application” ecc.), Questo timore non è certo fugato dai (pochi) testi dedicati ai VSTO ove tali lungaggini abbondano, In realtà la regola del “sottinteso”, che permette di omettere nonni e babbi quando non c’è ambiguità per fortuna vale pure nei VSTO.

Esempi.

Range(“A1:A10”).Value = ... in ambiente Excel è accettato assumendo l’intervallo A1.A10 del foglio corrente. Non, invece ActiveCell, che pretende almeno Application.ActiveCell (poco male).

Dim MiaZona As Excel.Range è sufficiente (sempre in ambiente Excel) in luogo del terrificante Microsoft.Office.Interop.Excel.Range. Ma As Range è rifiutato.

§                    Manca il Registratore di macro. È vero che conoscendo il modello a oggetti se ne può, anzi è meglio!, farne a meno, però resta comodo per la scoperta di proprietà/metodi meno noti. Usare il VBA? Sì, però attenti alle discrasie sintattiche... E col C# che succede?

Ripeto che i VSTO in Excel non permettono di associare codice VSTO a immagini e oggetti incorporati (possibilità ergonomica efficace), inoltre sembrano assenti – salvo segreti che il guru Andrew ha accennato – i controlli “classici” di Excel (barra Moduli).

Naturalmente  c’è sempre la possibilità di ricorrere a macro VBA.

Fino alla ultima versione ‘v3’ i VSTO non permettevano la creazione di funzioni d’utente, fondamentali per modelli neanche troppo particolari. Anche qui c’è sempre la possibilità di ricorrere a Excel e/o macro VBA.

§                     Infine ricordo che persino in assenza di funzioni d’utente o altro codice VBA il codice incorporato nelle DLL NON agisce! Se le macro sono disabilitate. Vi sono precisi motivi tecnici per tale scelta? Non so dire. Di fatto essa annulla l’aspettativa di distribuire in modo decentrato modelli ad utenti che possedessero un’edizione Office deprivata del tutto dal VBA (garanzia estrema anti-macro che sta a cuore agli edp manager, no?).

PRO

§                     Consentono l’utilizzo della vasta gamma di controlli ActiveX e Windows Form del mondo VB .NET / 2005. Molto interessanti poi i controlli creabili “al volo” e associabili a codice (in verità qualcosa del genere esiste in VBA, v. On Action nella Guida VBA: OnAction si applica a controlli anche personali delle CommandBar e, in Excel, anche a oggetti Shape incorporati nel foglio).

§                     Idem per la possibilità alternativa di sfruttare anche il linguaggio C# nelle nuove “macro”: a beneficio dei programmatori Affezionati a tale linguaggio e rendendo loro più agevoli le integrazioni di codice VSTO in progetti più generali. Tale integrazione - VSTO in progetti più generali – è by the way un decisivo punto di forza (ma non resta pur sempre la tecnologia OLE Automation? Uno sviluppatore da me interpellato in merito mi ha detto che tale tecnologia “è obsoleta”. Sarà, ma di fatto i VSTO non possono non supportarla se si ha a cuore l’interoperabilità tra Word, Excel ecc.).

§                     La possibilità di gestire l’HTML (peraltro introdotta in Office 2007 VBA: sicuramente per gestire la natura HTML del Ribbon) apre nuovi orizzonti.

§                     Notevole, last but not least, il supporto dei database ADO .NET (in VBA ci si deve accontentare del buon vecchio ADO, peraltro sufficiente in ambiente singolo o PMI).

posted on giovedì 22 febbraio 2007 22.31