Questa mattina vi voglio rendere partecipi di un problema che ho riscontrato durante la creazione di un setup project per smart device, soprattutto se il progetto richiede l’utilizzo di P/Invoke. Questo problema causa la comparsa di una dipendenza verso l’assembly mscorlib.dll del .NET Framework 2.0, e di conseguenza la creazione di un pacchetto di installazione (CAB) un po’ più grande del dovuto.

Andiamo con ordine. Supponiamo di avere una solution composta da due progetti separati:

1. una normale Device Application per PPC/WM (che chiameremo TestForDeploy)
2. un Smart Device CAB Project che si occupa di installare l’applicazione al punto 1 (che chiameremo Deploy)

Il template dell’applicazione generato da Visual Studio (sia 2005 che 2008) crea un’applicazione perfettamente funzionante. C’è solo una Windows Form che lui chiama Form1. Di conseguenza, le dipendenze richieste da entrambi i progetti sono puliti e sono il minimo indispensabile.

Ho volutamente espansi i nodi References e Detected Dependencies per mostrare l’elenco degli assembly richiesti dall’uno e dall’altro progetto.

Ora supponiamo che la nostra applicazione TestForDeploy debba utilizzare una COM Library scritta in C++. Per farlo dobbiamo far uso di una tecnologia chiamata P/Invoke: in pratica di tratta di creare una classe wrapper che mappa tutte le funzioni esposte dalla libreria natina. Questa classe wrapper viene creata on-demand da Visual Studio nel momento in cui la aggiungiamo ai riferimenti. Otteniamo lo stesso risultato utilizzando il tool da linea di comando tlbimp.exe, che crea un’assembly .NET partendo da una .dll in native code.

Ora, supponiamo di avere una libreria in D:Temp e che essa si chiami ComLibrary.dll.

Nel momento in cui la aggiungiamo alle References richieste da TestForDeploy, cambiano un bel po’ di cose, come si vede dallo screenshot qui sotto:

Ho tracciato delle linee rosse per nascondere la libreria, il cui nome rileva informazioni che preferisco non divulgare.

Osservate le Detected Dependencies rilevate dal progetto di setup: esso contiene l’assembly mscorlib due volte. Uno è l’mscorlib.dll del Compact Framework, mentre l’altro è l’mscorlib.DLL del .NET Framework per Desktop. Il resto dei files è corretto: viene inclusa la libreria in native code e viene incluso l’assembly che contiene la classe wrapper.

Se mantenessimo le cose così come sono, il file .CAB installerebbe su PPC/WM anche l’assembly mscorlib.DLL del .NET Framework. Onestamente, non so dire cosa accade: so solo che il .CAB raddoppia le sue dimensioni (da circa 3Mb passa a 6Mb – proprio a causa di quella dipendenza in più).

Di chi è la colpa? Googlando ho trovato diverse informazioni sui forum di Microsoft. Sui post si legge che la creazione della classe wrapper (e quindi l’uso più o meno esplicito di tlbimp.exe) prevede la dipendenza da mscorlib.DLL. Quindi sembra essere un problema di questo tool. Ho provato a lanciarlo da linea di comando per vederne i parametri (l’avevo studiato per qualche esame di certificazione, ma chi se lo ricordava più??). Esiste un parametro /reference che serve per indicare uno o più assembly che tlbimp.exe deve utilizzare per risolvere la definizione dei tipi, ma non è servito a nulla.

L’unico possibile workaround è quello di escludere quel mscorlib.DLL dal progetto di setup. Come? Semplicemente cliccandoci sopra col destro e selezionando Exclude dal menù contestuale, come si vede qua sotto:

Purtroppo l’informazione su quali files escludere non è persistita da nessuna parte da Visual Studio. Ciò significa che la volta successiva in cui aprirete l’IDE vi ritroverete nuovamente quel file incluso, e non c’è verso di fargli capire che non lo si vuole installare.

La feature di Detected Dependencies è propria dell’IDE di Visual Studio. Perchè dico questo? Perchè se avete rimosso il file come vi ho fatto vedere e utilizzare il tool msbuild.exe per rigenerare il file .CAB per la vostra installazione, quel file a tutti gli effetti sparisce dal vostro CAB.

Dovete solo ricordarvi di toglierlo ogni volta, prima di rigenerare il CAB. Ritengo comunque che se il problema fosse gestito a monte, all’interno della classe wrapper per intenderci, sarebbe molto meglio.

Send to Kindle

Oggi pomeriggio, parlando davanti alla macchinetta del caffè con due colleghi, ho ricordato loro che con Visual Studio 2008 è possibile vedere e debuggare i sorgenti del .NET Framework.

Scrissi un post il 19 Gennaio di quest’anno dove dicevo questa cosa, probabilmente appena scaricato Visual Studio 2008 dal mio abbonamento MSDN.

Dopo molti mesi mi chiedo: quanti hanno davvero avuto questa necessità? Credo una piccolissima parte. Certo, ci saranno esperti e guru in tutto il mondo che grazie a questa feature hanno scoperto bug o capito determinati comportamenti behind-the-scenes del .NET Framework, ma credo proprio che al 99% degli sviluppatori non abbia fatto nè caldo nè freddo.

Però dire che Microsoft ha dato questa impronta open-source ha un suo fascino, no?

Send to Kindle

SQL Server Management Studio permette di lavorare anche con database SQL Server Mobile. Quest’ultimo è un piccolo motore di database che gira su device Pocket PC e Windows Mobile, le cui capacità sono ovviamente ridotte rispetto al classico SQL Server che conosciamo. E’ comunque un’ottima soluzione per avere un database relazionale

I database SQL Server Mobile sono semplici files .sdf. Tramite SQL Server Management Studio possiamo aprire e lavorare questi files, indipendentemente dal fatto che essi si trovino sul nostro PC fisico, su un palmare o addirittura su un emulatore di palmare. Vediamo tutti e tre i casi, perchè ci sono alcuni aspetti che meritano di essere discussi.

Apertura di un database su un PC fisico
Nelle prime fasi di sviluppo è comodo cominciare a lavorare su un nuovo database, senza aver per forza un palmare fisico. Questo significa che possiamo creare un file .sdf sul PC di sviluppo, magari nella directory della solution. Con SQL Server Management Studio possiamo aprire il file dalla finestra Connect To Server e specificare il file con il suo path locale. Ricordiamoci di selezionare la voce SQL Server Mobile nella casella Server Type.

Nulla di che, giusto?

Apertura di un database su Pocket PC/Windows Mobile
Per aprire un file .sdf presente su un device mobile è necessario che quest’ultimo sia connesso via ActiveSync oppure via Windows Mobile Device Center (questo dipende dall’OS che usate: Windows XP oppure Windows Vista). Dalla finestra Connect To Server è necessario specificare il path che punti innanzitutto al device e poi via via specifichi il percorso corretto:

Nell’immagine qui sopra si vede che il path è Mobile DeviceSDMMC Diskdatabase.sdf. Se non conoscete il percorso giusto basta aprire la casella e cliccare su <Browse for more…>. Nel caso che ho preso io come esempio, il file .sdf è stato salvato sulla SD interna del palmare: questo chiaramente non è sempre così. Dipende dalla lingua e dal tipo di supporto che usate.

Apertura di un database su un emulatore
Il pacchetto Visual Studio 2005/2008 mette a disposizione un emulatore su cui possono girare sistemi operativi come Pocket PC e Windows Mobile. Se non avete esigenze particolari questo emulatore è l’ideale per cominciare a sviluppare qualcosa, soprattutto se non avete a disposizione un palmare reale.

Per aprire il manager degli emulatori basta andare sul menù Tools –> Device Emulator Manager di Visual Studio. Apparirà una finestra con l’elenco di tutte le immagini di palmari che avete installato. Cliccate con il destro su una qualsiasi voce e poi cliccate Connect: in pochi secondi verrà avviato sullo schermo un vero e proprio palmare, su cui potete fare tutte le installazioni che volete, come se fosse un palmare fisico vero e proprio.

A questo punto la domanda è: come faccio ad aprire un file .sdf che sta su un emulatore? Torniamo al passo precedente: abbiamo visto come SQL Server Management Studio possa collegarsi al dispositivo connesso via ActiveSync. E’ possibile collegare l’emulatore ad ActiveSync, così da far credere a quest’ultimo di aver a che fare con un vero palmare? Certamente sì! Cosa starei qui a parlare, se no?

Per farlo, avviate un emulatore qualsiasi dal Device Emulator Manager. Una volta che l’emulatore è partito, cliccateci sopra con il destro e cliccate sulla voce Cradle. Ricordatevi di aver selezionato la voce DMA nelle connessioni consentite da ActiveSync.

Se tutto è andato a buon fine, vedrete ActiveSync che rileva il dispositivo e si connette, esattamente come farebbe con un palmare vero. A questo punto, è sufficiente seguire la stessa procedura che abbiamo visto prima.

Send to Kindle