DevExperience

.Net Framework, Embedded Systems & Design Patterns Paolo Patierno's Blog

MVP Award

I'm Microsoft MVP for Windows Embedded

Recent Posts

Apps & Articles

Applicazioni

Pubblicazioni

Tags

My Profiles

 

My Embedded101 Blog

My YouTube Channel

Windows Embedded CE 6.0

Building Embedded Devices using Windows Embedded CE 6.0 R2

Archives

Sto leggendo...

Windows Embedded

.Net Micro Framework

.Net Framework & CLR

Email Notifications

Open Source Hardware

RSS Blog Post

M2Mqtt : release 3.3.0.0 per il client MQTT su piattaforma .Net

Lo sviluppo della libreria M2Mqtt continua …. ormai giunta alla versione 3.3.0.0 !

Questa volta le nuove funizionalità riguardano due richieste provenienti dalle persone che la stanno utilizzando.

In primo luogo, ho aggiunto più overload al metodo Connect(), poichè da quanto ho rimosso i parametri di default (per questioni di compatibilità con le versioni precedenti del .Net Framework) ho lasciato il costruttore più complesso che richiede tutti i parametri. Molte persone, non conoscendo bene il protocollo MQTT, si sono trovate in difficoltà nel decidere quali valori passare ai parametri meno noti (will message, clean session, …).

L’ulteriore nuova funzionalità riguarda l’evento di disconnessione del client dal broker MQTT che è stato richiesto sul sito ufficiale CodePlex. La classe MqttClient espone l’evento MqttMsgDisconnected che viene sollevato quando è rilevata una condizione di mancata connessione con il broker e tipicamente in due casi :

  • In caso di assenza di traffico dati, al messaggio di PINGREQ (relativo al keep alive) non si riceve la risposta PINGRESP dal broker;
  • La trasmissione o la ricezione dati verso/da il broker fallisce per un problema di connessione;

Anche questa volta la nuova versione è disponibile su CodePlex e su Nuget, oltre ad aver aggiornato il corrispondente componente M2Mqtt4CE per Windows Embedded Compact 2013 !

Breaking changes ….

Per quanto riguarda Nuget, gli assemblies M2Mqtt relativi al .Net Micro Framework 4.3 sono stati aggiornati all’ultima release QFE1; essi non funzionano con la versione RTM precedente, poichè gli assemblies del micro framework sono passati dalla versione 4.3.0.0 alla 4.3.1.0.

Raspberry Pi e Windows Azure Service Bus via AMQP con la libreria Qpid Proton C

Nel corso di questa tutorial vedremo in che modo sia possibile utilizzare la Raspberry Pi come client AMQP (Advanced Message Queuing Protocol) e collegarla al Windows Azure Service Bus che supporta la versione AMQP 1.0.

Ovviamente, la scelta della libreria client da utilizzare è quasi obbligata : Apache Qpid Proton. Tale libreria sviluppata in C fornisce comunque il bindings per altri linguaggi tra cui Java, Python e PHP ma nel corso dell’articolo utilizzeremo solo la versione nativa.

Generalmente, la Raspberry Pi viene utilizzata con la distribuzione Raspbian (basata su Debian) che è a tutti gli effetti una distribuzione Linux. Ciò vuol dire che possiamo installare la libreria Qpid Proton come faremo su un normale distribuzione Ubuntu su un PC oppure su una macchina virtuale ad esempio su Windows Azure.

Connessione alla Raspberry Pi

Tutte le operazioni che seguono possono essere effettuate accedendo direttamente alla Raspberry Pi attraverso un monitor, una tastiera ed un mouse collegati ad essa oppure in remoto attraverso l’utilizzo di SSH.

La seconda soluzione è sicuramente la più comoda, utilizzado un tool come Putty e specificando l’indirizzo IP della nostra board, la porta (tipicamente la 22) ed il tipo di connessione (SSH).

01

02

Installazione dei prerequisiti

Una volta effettuato l’accesso, in primo luogo bisogna installare dei componenti fondamentali tra cui GCC, CMAKE (sistema di build utilizzato da Qpid) e la libreria UUID per la generazione di identificativi univoci.

sudo apt-get install gcc cmake uuid-dev

Poichè Qpid utilizza SSL e il Service Bus necessita di questo prerequisito per la connessione, dobbiamo installare OpenSSL nel nostro sistema (che in realtà potrebbe essere già installato).

sudo apt-get install openssl

La presenza della libreria OpenSSL non include la presenza degli header file e delle librerie statiche necessarie per lo sviluppo. Bisogna quindi installare la libssl-dev.

sudo apt-get install libssl-dev

Non essendo interessato ad alcun binding con altri linguaggi, possiamo evitare di installare i package per Python, PHP e così via, passando direttamente al download della libreria dal sito ufficiale. Inoltre, non installiamo le dipendenze che riguardano la generazione automatica della documentazione.

Download e compilazione della Qpid Proton

Dal sito ufficiale possiamo ricavare uno dei mirror da cui scaricare la libreria nella sezione “Download” per poi scaricarla usando il tool WGET.

pi@raspberrypi ~ $ wget http://apache.fastbull.org/qpid/proton/0.6/qpid-proton-0.6.tar.gz
--2014-04-16 07:09:52--  http://apache.fastbull.org/qpid/proton/0.6/qpid-proton-0.6.tar.gz
Resolving apache.fastbull.org (apache.fastbull.org)... 194.116.84.14
Connecting to apache.fastbull.org (apache.fastbull.org)|194.116.84.14|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 629147 (614K) [application/x-gzip]
Saving to: `qpid-proton-0.6.tar.gz'

100%[======================================>] 629,147     1.00M/s   in 0.6s

2014-04-16 07:09:53 (1.00 MB/s) - `qpid-proton-0.6.tar.gz' saved [629147/629147]

Dopo il download. estraiamo il contenuto del file.

tar xvfz qpid-proton-0.6.tar.gz

Entriamo nella cartella appena create (qpid-proton-0.6) e creiamo una cartella “build” in cui faremo generare dal tool CMAKE il corrispondente Makefile per la compilazione della libreria.

mkdir build

cd build

cmake -DCMAKE_INSTALL_PREFIX=/usr ..

L’output del comando cmake dovrebbe essere il seguente.

pi@raspberrypi ~/qpid-proton-0.6/build $ cmake -DCMAKE_INSTALL_PREFIX=/usr ..
-- The C compiler identification is GNU 4.6.3
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- PN_VERSION: 0.6
-- Found Java: /usr/bin/java
-- Java version: 1.7.0.40. javac is at: /usr/bin/javac
-- Locations of Bouncycastle 1.47 jars: BOUNCYCASTLE_BCPROV_JAR-NOTFOUND BOUNCYCASTLE_BCPKIX_JAR-NOTFOUND
-- Won't build proton-j-impl because one or more Bouncycastle jars were not found. PROTON_JAR_DEPEND_DIR was: /usr/share/java
-- Found OpenSSL: /usr/lib/arm-linux-gnueabihf/libssl.so;/usr/lib/arm-linux-gnueabihf/libcrypto.so (found version "1.0.1e")
-- Looking for clock_gettime
-- Looking for clock_gettime - not found.
-- Looking for clock_gettime in rt
-- Looking for clock_gettime in rt - found
-- Looking for uuid_generate
-- Looking for uuid_generate - not found.
-- Looking for uuid_generate in uuid
-- Looking for uuid_generate in uuid - found
-- Looking for strerror_r
-- Looking for strerror_r - found
-- Looking for atoll
-- Looking for atoll - found
-- Could NOT find SWIG (missing:  SWIG_EXECUTABLE SWIG_DIR)
-- Could NOT find Doxygen (missing:  DOXYGEN_EXECUTABLE)
-- Looking for include file inttypes.h
-- Looking for include file inttypes.h - found
-- Can't locate the valgrind command; no run-time error detection
-- Cannot find rspec, skipping rspec tests
-- Cannot find both Java and Maven: testing disabled for Proton-J and JNI Bindings
-- Configuring done
-- Generating done
-- Build files have been written to: /home/pi/qpid-proton-0.6/build

Ci sono alcuni warning sull’impossibilità di trovare il runtime Java, Swig e Doxygen. Come già anticipato, non siamo interessato al binding con altri linguaggi ed alla generazione automatica della documentazione per cui possiamo non preoccuparci di tali warning.

L’ultimo step consiste nell’utilizzare il tool MAKE per elaborare il Makefile appena generato da cmake ed installare la libreria nel sistema.

sudo make install

Al termine della compilazione, la libreria è installata nel sistema in corrispondenza della cartella /usr (come specificato nel primo comando CMAKE eseguito) ed in particolare :

  • /usr/share/proton : contiene un esempio di utilizzo;

  • /usr/bin e /usr/lib : contengono i file relativi la libreria vera e propria;

  • /usr/include/proton : contiene gli header file necessari per lo sviluppo di un’applicazione;

Esempio di invio e ricezione su Service Bus

Per poter testare il corretto funzionamento della libreria utilizziamo i semplici esempi di send e receive distribuiti con la libreria stessa durante l’installazione.

cd /usr/share/proton/examples/messenger/

Anche in questo caso possiamo sfruttare il tool CMAKE per la generazione del Makefile necessario alla compilazione (da notare che è necessario l’esecuzione come Super User).

sudo mkdir build

cd build

sudo cmake ..

sudo make all

Al termine della compilazione avremo i due file eseguibili recv e send corrispondenti a due semplici applicativi che permettono di ricevere ed inviare messaggi ad una coda via AMQP.

Per fare questo, creiamo un nuovo namespace per il Service Bus sul portale di Microsoft Azure ed in corrispondenza di questo anche una queue. Nel mio caso, il namespace è qpidproton.servicebus.windows.net e la coda banalmente “myqueue”. Attraverso il portale dobbiamo ricavare due parametri fondamentali per la connessione che sono lo SharedSecretIssuer (tipicamente “owner”) e lo SharedSecretValue.

03

L’indirizzo per la connessione al Service Bus avrà la seguente struttura :

amqps://username:password@namespace.servicebus.windows.net/queue_name

Poichè il Service Bus usa le connessioni SSL, dobbiamo utilizzare AMQPS in luogo del semplice AMQP.

Per inviare un messaggio con testo “Hello” alla queue dobbiamo eseguire l’applicazione send nel modo seguente.

./send –a amqps://username:password@namespace.servicebus.windows.net/queue_name Hello

Per poter ricevere un messaggio dalla stessa queue possiamo utilizzare l’applicazione recv nel modo seguente.

./recv amqps://username:password@namespace.servicebus.windows.net/queue_name

Con un risultato di questo tipo.

Address: amqps://username:password@namespace.servicebus.windows.net/queue_name
Subject: (no subject)
Content: "Hello"

Microsoft Azure per l’Internet of Things

Immagine

Come ulteriore conferma che la Microsoft vuole entrare a far parte del business dell’Internet of Things, è stata rilasciata una “limited preview” di un nuovo prodotto su Azure : Microsoft Azure Intelligent System Service.

L’obiettivo primario è quello di fornire un’unica piattaforma in grado di acquisire dati generati da sistemi eterogenei (e quindi anche non Microsoft) per poterli elaborare ed analizzare in tempo reale con strumenti come HDInsight.

Le principali potenzialità saranno :

  • Connettività : possibilità di connettere un qualsiasi device indipendentemente dal sistema operativo onboard;
  • Configurazione : definizione di regole per automatizzare i processi sui device;
  • Amministrazione : possibilità di monitorare, configurare ed aggiornare i device sul campo;
  • Estendibilità : maggiore scalabilità ed efficienza grazie all’infrastruttura basata sul Cloud;

Al seguente link, è possibili richiedere la limited preview alla quale avranno accesso i potenziali utilizzatori a seguito di un questionario con cui valutare il progetto da realizzare.

Qpid Proton C su una macchina virtuale Ubuntu Server 12.04 in Windows Azure per l’utilizzo del Service Bus con AMQP : creazione, configurazione, compilazione ed uso

Uno dei protocolli maggiormente utilizzati nell’ambito del messaging che può trovare applicazione anche nell’Internet of Things è l’AMQP (Advanced Message Queuing Protocol), ormai già standard OASIS da alcuni anni e giunto alla versione 1.0.

Il servizio Service Bus offerto da Windows Azure supporta tale protocollo che, essendo standard, garantisce la comunicazione tra client sviluppati su piattaforme diverse. Nel caso di una piattaforma Microsoft non abbiamo alcun problema grazie al Windows Azure SDK (giunto alla versione 2.3) che astrae completamente il protocollo di comunicazione sottostante con il Service Bus (AMQP, SBMP, …) grazie al suo modello di programmazione.

Nel caso in cui ci troviamo a lavorare su un sistema non Microsoft, una delle migliori scelte è quella di adottare le librerie del progetto Apache Qpid ed in particolare la Qpid Proton. Tale libreria sviluppata in C fornisce comunque il bindings per altri linguaggi tra cui Java, Python e PHP.

Nel corso di questo tutorial, vedremo come sia possibile creare una macchina virtuale Ubuntu Server 12.04 su Windows Azure, installare ed utilizzare la libreria Qpid Proton per inviare e ricevere messaggi attraverso il Service Bus con il protocollo AMQP. Ovviamente, tale procedura può essere utilizzata anche nel caso di un qualsiasi sistema Ubuntu 12.04 (anche client e non server) non necessariamente su Windows Azure ma sul nostro PC in locale.

Creazione della macchina virtuale su Windows Azure

In primo luogo dobbiamo creare una macchina virtuale con il sistema operativo Ubuntu Server 12.04 LTS su Windows Azure. Per farlo, è necessario collegarsi al Management Portal e loggarsi con il proprio account. Una volta loggati, selezioniamo sulla sinistra “Virtual Machines” e cliccate su “Create a Virtual Machine”; utilizziamo l’opzione di “Quick create” impostando :

  • DNS Name : il nome DNS da assegnare alla macchina virtuale;
  • Image : l’immagine del sistema operativo da utilizzare che in questo caso è “Ubuntu Server 12.04 LTS”;
  • Size : la “dimensione” della macchina virtuale in base alle nostre necessità;
  • New password/Confirm : password e relativa conferma per l’utente creato di default che si chiama “azureuser”;
  • Region/Affinity Group : la regione (data center) in cui creare la nostra macchina virtuale;

Clicchiamo su “Create a virtual machine” per avviare la creazione della macchina virtuale.

01_create_vm

Al termine del processo di creazione che dura alcuni minuti avremo la conferma.

02_vm_created

Per poterci collegare alla macchina virtuale in remoto, è necessario conoscere l’endpoint per l’accesso via SSH che possiamo trovare cliccando sul nome della macchina virtuale appena creata (nel mio caso ppatiernoubuntu) e poi sul tab “Endpoints” (nel mio caso la porta è la 22).

03_SSH_endpoint

Scarichiamo un client Telnet come Putty per poterci collegare, inserendo l’host name e la porta corretta.

04_Putty

All’apertura della console digitiamo “azureuser” come nome utente e la corrispondente password che abbiamo scelto nella fase di creazione della macchina virtuale.

Installazione dei prerequisiti

Il file README distribuito con la libreria Qpid Proton descrive abbastanza nel dettaglio la procedura per l’installazione della libreria ma fa riferimento al tool YUM che su Ubuntu non abbiamo nativamente a disposizione; in luogo di esso usiamo APT. Inoltre, alcune libreria non hanno esattamente lo stesso nome come descritto nel file README.

In genere, la prima operazione che faccio su una macchina Ubuntu è quella di installare il package “build-essential” con tutti gli strumenti principali per la compilazione, eseguendo il comando :

sudo apt-get install build-essential

Il passo successivo è quello di installare le dipendenze principali tra cui GCC (che avremo già installato grazie al package “build-essential”), CMAKE (sistema di build utilizzato da Qpid) e la libreria UUID per la generazione di identificativi univoci (un pò come il nostro caro Guid).

sudo apt-get install gcc cmake uuid-dev

Poichè Qpid utilizza SSL e il Service Bus necessita di questo prerequisito per la connessione, dobbiamo installare OpenSSL nel nostro sistema (che in realtà potrebbe essere già installato).

sudo apt-get install openssl

La presenza della libreria OpenSSL non include la presenza degli header file e delle librerie statiche necessarie per lo sviluppo. Bisogna quindi installare la libssl-dev.

sudo apt-get install libssl-dev

Non essendo interessato ad alcun binding con altri linguaggi, possiamo evitare di installare i package per Python, PHP e così via, passando direttamente al download della libreria dal sito ufficiale. Inoltre, non installiamo le dipendenze che riguardano la generazione automatica della documentazione.

Download e compilazione della Qpid Proton

Dal sito ufficiale possiamo ricavare uno dei mirror da cui scaricare la libreria nella sezione “Download” per poi scaricarla usando il tool WGET.

azureuser@ppatiernoubuntu:~$ wget http://apache.fastbull.org/qpid/proton/0.6/qpid-proton-0.6.tar.gz
--2014-04-16 07:09:52-- 
http://apache.fastbull.org/qpid/proton/0.6/qpid-proton-0.6.tar.gz
Resolving apache.fastbull.org (apache.fastbull.org)... 194.116.84.14
Connecting to apache.fastbull.org (apache.fastbull.org)|194.116.84.14|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 629147 (614K) [application/x-gzip]
Saving to: `qpid-proton-0.6.tar.gz'

100%[======================================>] 629,147     1.00M/s   in 0.6s

2014-04-16 07:09:53 (1.00 MB/s) - `qpid-proton-0.6.tar.gz' saved [629147/629147]

Dopo il download. estraiamo il contenuto del file.

tar xvfz qpid-proton-0.6.tar.gz

Entriamo nella cartella appena create (qpid-proton-0.6) e creiamo una cartella “build” in cui faremo generare dal tool CMAKE il corrispondente Makefile per la compilazione della libreria.

mkdir build

cd build

cmake -DCMAKE_INSTALL_PREFIX=/usr ..

L’output del comando cmake dovrebbe essere il seguente.

azureuser@ppatiernoubuntu:~/qpid-proton-0.6/build$ cmake -DCMAKE_INSTALL_PREFIX=/usr ..
-- The C compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- PN_VERSION: 0.6
-- Could NOT find Java (missing:  Java_JAVA_EXECUTABLE Java_JAR_EXECUTABLE Java_JAVAC_EXECUTABLE Java_JAVAH_EXECUTABLE Java_JAVADOC_EXECUTABLE)
-- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libssl.so;/usr/lib/x86_64-linux-gnu/libcrypto.so (found version "1..1")
-- Looking for clock_gettime
-- Looking for clock_gettime - not found.
-- Looking for clock_gettime in rt
-- Looking for clock_gettime in rt - found
-- Looking for uuid_generate
-- Looking for uuid_generate - not found.
-- Looking for uuid_generate in uuid
-- Looking for uuid_generate in uuid - found
-- Looking for strerror_r
-- Looking for strerror_r - found
-- Looking for atoll
-- Looking for atoll - found
-- Could NOT find SWIG (missing:  SWIG_EXECUTABLE SWIG_DIR)
-- Could NOT find Doxygen (missing:  DOXYGEN_EXECUTABLE)
-- Looking for include files INTTYPES_AVAILABLE
-- Looking for include files INTTYPES_AVAILABLE - found
-- Can't locate the valgrind command; no run-time error detection
-- Cannot find ruby, skipping ruby tests
-- Cannot find both Java and Maven: testing disabled for Proton-J and JNI Bindings
-- Configuring done
-- Generating done
-- Build files have been written to: /home/azureuser/qpid-proton-0.6/build

Ci sono alcuni warning sull’impossibilità di trovare il runtime Java, Swig e Doxygen. Come già anticipato, non siamo interessato al binding con altri linguaggi ed alla generazione automatica della documentazione per cui possiamo non preoccuparci di tali warning.

L’ultimo step consiste nell’utilizzare il tool MAKE per elaborare il Makefile appena generato da cmake ed installare la libreria nel sistema.

sudo make install

Al termine della compilazione, la libreria è installata nel sistema in corrispondenza della cartella /usr (come specificato nel primo comando CMAKE eseguito) ed in particolare :

  • /usr/share/proton : contiene un esempio di utilizzo;
  • /usr/bin e /usr/lib : contengono i file relativi la libreria vera e propria;
  • /usr/include/proton : contiene gli header file necessari per lo sviluppo di un’applicazione;

Esempio di invio e ricezione su Service Bus

Per poter testare il corretto funzionamento della libreria utilizziamo i semplici esempi di send e receive distribuiti con la libreria stessa durante l’installazione.

cd /usr/share/proton/examples/messenger/

Anche in questo caso possiamo sfruttare il tool CMAKE per la generazione del Makefile necessario alla compilazione (da notare che è necessario l’esecuzione come Super User).

sudo mkdir build

cd build

sudo cmake ..

sudo make all

Al termine della compilazione avremo i due file eseguibili recv e send corrispondenti a due semplici applicativi che permettono di ricevere ed inviare messaggi ad una coda via AMQP.

Per fare questo, creiamo un nuovo namespace per il Service Bus sul portale di Microsoft Azure ed in corrispondenza di questo anche una queue. Nel mio caso, il namespace è qpidproton.servicebus.windows.net e la coda banalmente “myqueue”. Attraverso il portale dobbiamo ricavare due parametri fondamentali per la connessione che sono lo SharedSecretIssuer (tipicamente “owner”) e lo SharedSecretValue.

05_sb_access

L’indirizzo per la connessione al Service Bus avrà la seguente struttura :

amqps://username:password@namespace.servicebus.windows.net/queue_name

Poichè il Service Bus usa le connessioni SSL, dobbiamo utilizzare AMQPS in luogo del semplice AMQP.

Per inviare un messaggio con testo “Hello” alla queue dobbiamo eseguire l’applicazione send nel modo seguente.

./send –a amqps://username:password@namespace.servicebus.windows.net/queue_name Hello

Per poter ricevere un messaggio dalla stessa queue possiamo utilizzare l’applicazione recv nel modo seguente.

./recv amqps://username:password@namespace.servicebus.windows.net/queue_name

Con un risultato di questo tipo.

Address: amqps://username:password@namespace.servicebus.windows.net/queue_name
Subject: (no subject)
Content: "Hello"

GnatMQ : un broker MQTT per il .Net Framework

Cattura

Con una settimana di ritardo rispetto l’uscita prevista, ho finalmente rilasciato in versione Beta un broker MQTT completamente sviluppato in C# e che può essere eseguito con il .Net Framework ed il .Net Compact Framework 3.9 (su sistemi con Windows Embedded Compact 2013) … il suo nome è GnatMQ !

Al suo interno pulsa il cuore della libreria M2Mqtt con la quale condivide il “core” del protocollo MQTT, per quanto riguarda la parte di connessione al client e la gestione dei messaggi.

Ovviamente, è completamente open source e disponibile su CodePlex ma è attualmente in versione Beta (aspetto numerose segnalazioni da parte vostra !).

Come riportato nella pagina di documentazione supporta le seguenti funzionalità :

  • Tutti i livelli di QoS del protocollo MQTT;
  • Flag Clean Session alla connessione di un client;
  • Flag di Retained Message;
  • Will Message con relativo QoS e topic;
  • Autorizzazione con username e password;
  • Sottoscrizione ai topic con wildcards;
  • Publish e subscribe mediante una “inflight queue”;

Tra le funzionalità non ancora supportate abbiamo :

  • Configurazione del broker da un file di configurazione;
  • Sicurezza basata su SSL/TLS;
  • Configurazione bridge (broker to broker);
  • Salvataggio permanente (es. database) delle sessioni, retained message e will message;

Il mio obiettivo è di supportare lo sviluppo di questo broker così come per la libreria M2Mqtt nella speranza che possa essere utilizzato e migliorato grazie alle vostre segnalazioni !

Per poterne seguire l’evoluzione è possibile utilizzare anche la relativa pagina Facebook ed account Twitter.

Microsoft MVP per Windows Embedded !!

Ieri, il mio lavoro pomeridiano è stato interrotto da una delle mail più belle che potessi ricevere : sono stato nominato Microsoft MVP per la categoria Windows Embedded !!

Cattura

Questo premio è il frutto della mia passione e della voglia di condividere le mie conoscenze che nasce nel 2011, anno in cui ho iniziato a seguire gli eventi della mia attuale community DotNetCampania, di cui sono successivamente diventato socio. Rapito dall’animo con cui erano tenuti gli eventi, ho deciso di diventarne parte attiva ed il mio primo grazie va a tutti coloro che ve ne fanno parte, perché è soprattutto grazie a loro che ho ricevuto questo riconoscimento che ovviamente è di tutti !

Grazie a colei che è diventata la mia MVP community lead , Cristina Gonzalez Herrero, con la quale da ieri è iniziato questo percorso e che mi seguirà nel corso di questo anno.

Grazie a tutti gli MVP italiani su Windows Embedded che hanno creduto in me. Nell’ordine con cui li ho conosciuti nel tempo, un grazie a Valter Minute, il primo guru e simbolo dell’embedded in Italia che seguivo e leggevo solo sui forum e che ho poi conosciuto personalmente ad un corso (tenuto da lui ovviamente!). Il guru oggi è ormai un grande amico !

Grazie a Lorenzo Maiorfi che ha avuto l’intuizione di fondare la community TinyCLR.it, chiedendomi di farne parte e coinvolgendo tante altre persone; abbiamo un’anima “nerd” che ci accomuna ! Grazie a lui ho anche conosciuto il mitico Mirco Vanini che ha sempre dispensato ottimi consigli di lavoro e di vita, credendo in ciò che faccio. Auguro a tutti di conoscere una persona come lui !

Grazie a Beppe Platania e Gianni Rosa Gallina che hanno accettato volentieri i miei inviti alle due edizioni della Microsoft Embedded Conference organizzata a Napoli dal DotNetCampania, rendendo l’evento ancora più speciale e ricco di contenuti di alto livello. Spero di poterli ricambiare magari con una conferenza a Torino, a casa loro !

Un grazie a Samuel Phung, mitico MVP americano da ormai 10 anni, che ha osservato interessato i miei articoli sul blog della sua community Embedded101 iniziando con me un rapporto non solo tecnico ma soprattutto di amicizia, rendendomi addirittura “board of director” member della community stessa insieme a David Jones, Thierry Joubert e Ron Kessler … una grande famiglia di guru dell’embedded !

L’ultimo ma sicuramente il più importante grazie va a mia moglie Sara ed al mio piccolo Christian, che quotidianamente si vedono privati della mia presenza (fisica e non … talvolta ci sono con il corpo ma la mia testa sta sviluppando) nel dedicare il mio tempo alle attività di community. Hanno accettato e capito che questo è il mio modo di vivere la mia passione ! Comunque sia mi supportano ogni giorno ! Vi amo da morire !

Questo rappresenta per me solo un punto di partenza per fare sempre meglio … e come diceva un vecchio film … “da grandi poteri derivano grandi responsabilità”.

Occhiolino

Welcome to the Internet of Your Things !!

IoYT

Oggi è “comparso” un nuovo sito web dedicato all’Internet of Things da parte della Microsoft che parla di Internet of Your Things per evidenziare che l’IoT può essere realizzato da ciascuno di noi con le proprie “cose” che possiamo interconnettere fra loro attraverso il Cloud.

Sul sito è possibile trovare tutte le informazioni su questo nuovo (o già maturo ?) progetto su cui la Microsoft sta orientando il proprio business utilizzando quanto già di buono ha per il mondo embedded (tutti i sistemi operativi della famiglia Windows Embedded ai quali aggiungerei il .Net Micro Framework) ed unendolo a quanto di potente ha con il Cloud (Microsoft Azure è noto a tutti).

E’ proprio vero che ciò che ha detto il nuovo CEO Satya Nadella nell’intenzione di volere “a cloud for everyone, on every device” per cui il #cloud4device può essere inteso nell’accezione più generale, non solo smartphone e tablet ma device e “cose” che si collegano alla grande rete !

Ci si può iscrivere ad una newsletter che però inizierà il 1° Luglio … forse a partire da quella data … ne vedremo di “cose” belle !!

M2Mqtt : bug fix e nuova versione 3.2.0.0

Se utilizzando la versione 3.1.0.0 vi rendete conto che gli eventi di Connect e Disconnect non sono sollevati … è corretto … non sono gestiti nel client e dovete aggiornare la libreria oppure ignorarli !

Ho rilasciato un aggiornamento della libreria M2Mqtt (versione 3.2.0.0) che mette a posto questa dimenticanza.

A seguito della fusione del codice tra la libreria client M2Mqtt ed il futuro broker GnatMQ ho commesso l’errore di includere la gestione dei messaggi di SUBSCRIBE, UNSUBSCRIBE, CONNECT e DISCONNECT anche nel client (ovviamente senza alcun senso) con i corrispondenti eventi.

L’aggiornamento è disponibile come sempre anche su Nuget ed ho provveduto ad aggiornare anche il corrispondente componente M2Mqtt4CE per Windows Embedded Compact 2013.

M2Mqtt : MQTT per le piattaforme .Net con la nuova versione e sempre più social !

m2mqttpng

Ed anche questa volta arriva puntuale un aggiornamento per la mia libreria M2Mqtt ormai giunta alla versione 3.1.0.0 !

Le novità principali riguardano una migliore gestione del QoS Level 2, alcune proprietà del client esposte all’esterno ma soprattutto il fatto di aver valutato ed aggiunto alcune richieste che mi sono state fatte dagli utilizzatori che ovviamente ringrazio !

Inoltre, in alcune parti del codice sorgente potrete notare una direttiva di compilazione condizionata alla definizione del simbolo BROKER … perchè ? Ho uniformato il codice della libreria M2Mqtt al codice di un broker MQTT che sto sviluppando e che a breve sarà rilasciato in versione beta. Il suo nome è GnatMQ ed il progetto è già pubblicato online sempre su CodePlex e quindi open source. Attenzione che attualmente è ancora una versione in via di sviluppo e non completamente stabile ma il rilascio è imminente !

Oltre ad aggiornare il progetto su CodePlex, ho provveduto ad aggiornare il relativo package su Nuget (che ormai ha superato i 1000 download !), il codice nella Microsoft Gallery ed il progetto M2Mqtt4CE per includere il nuovo componente nelle proprie immagini di Windows Embedded Compact 2013.

L’ultima novità riguarda una libreria sempre più social ! Ho creato l’account twitter ufficiale @M2Mqtt e la pagina Facebook !

Non avete scuse per non poter seguire la sua evoluzione !

Packt Publishing celebra i 2000 titoli !

2000th-Book-Home-Page-Banner

Chi segue il mio blog sa che la casa editrice Packt Publishing è stata uno degli sponsor della Microsoft Embedded Conference 2014 tenutasi a Napoli il 15 Febbraio.

Volevo segnalarvi un’interessante promozione che sta tenendo in questi giorni per celebrare i 2000 titoli e che consiste nell’acquisto di un libro per riceverne un altro gratuitamente !

Al seguente link potete trovare tutte le informazioni su questa incredibile offerta !

Windows Embedded Compact 2013 : utilizziamo il componente proprietario M2Mqtt4CE in un’applicazione managed MQTT

Siamo giunti all’ultima puntata di questo tutorial che ci ha guidato attraverso la realizzazione di un componente proprietario (utilizzando la M2Mqtt library come esempio) per Platform Builder e la relativa inclusione nell’immagine di Windows Embedded Compact 2013. In questo ultimo post vedremo in che modo è possibile utilizzare questo componente in un’applicazione managed di esempio eseguendone anche il debugging.

SDK e Application Builder

Quando realizziamo un’immagine di Windows Embedded Compact 2013 che dobbiamo fornire al team di sviluppo software che realizzerà l’applicazione di alto livello per il target device, dobbiamo necessariamente mettere a disposizione anche il relativo SDK. Quest’ultimo contiene tutti gli header files e le librerie statiche che gli sviluppatori potranno utilizzare per la realizzazione di applicazioni in codice nativo, evitando di utilizzare delle API che non abbiamo incluso nella nostra immagine. Tipicamente non avremmo bisogno dell’SDK nel caso applicazioni managed con il .Net Compact Framework ma purtroppo senza alcun SDK installato, Visual Studio 2012 non rende disponibile alcun template per applicazioni basate su Windows Embedded Compact 2013. Tale SDK può essere creato e generato mediante Platform Builder cliccando su SDKs e poi su “Add New SDK”; il sistema di build produrrà un file .MSI da distribuire a chiuque ne abbia bisogno.

SDK

Oltre all’SDK, il team di sviluppo ha bisogno di installare Application Builder per Windows Embedded Compact 2013 che è possibile scaricare qui.

Per poter supportare il debugging attraverso Application Builder, è necessario includere il corrispondente componente “Application Builder Debugging Support” del catalog items nell’immagine e che possiamo trovare in Core OS –> Windows Embedded Compact –> Applications and Services Development –> Diagnostics and Debugging Tools.

AppBuilder_01

Utilizzando questi due strumenti, chi ha il compito di sviluppare le applicazioni per il target device e non il sistema operativo, non ha alcun bisogno di installare Platform Builder.

Sviluppo, distribuzione e debug di un’applicazione managed

Dopo aver installato l’SDK (generato a partire dall’immagine realizzata fino a questo punto del tutorial) ed Application Builder sul PC di sviluppo, avviamo Visual Studio 2012 e selezioniamo il template Visual C# –> Windows Embedded Compact 2013 –> <SDK generato> (nel mio caso VirtualCEPC2013); per il nostro esempio va benissimo una Console Application.

Managed_01

Aggiungiamo un reference all’assembly M2Mqtt (deve essere lo stesso distribuito con il componente M2Mqtt4CE avendo un Public Key Token) ma impostiamo la proprietà “Copy Local” a False, in modo che esso non sarà distribuito con l’applicazione essendo già incluso nell’immagine del sistema operativo.

Managed_02

Siamo pronti per scrivere la nostra applicazione che non farà altro che pubblicare periodicamente un messaggio con un dato random su un topic attraverso l’utilizzo del broker Mosquitto da installare su un PC.

   1: static void Main(string[] args)
   2: {
   3:     Console.WriteLine("Welcome to C# on Windows Embedded Systems");
   4:  
   5:     MqttClient client = new MqttClient(IPAddress.Parse("192.168.1.4"));
   6:     client.Connect("netcfclient");
   7:  
   8:     Random random = new Random();
   9:     while (true)
  10:     {
  11:         int data = random.Next(10);
  12:         client.Publish("/data", Encoding.ASCII.GetBytes(data.ToString()));
  13:         Thread.Sleep(1000);
  14:     }
  15: }

Avviamo il target device (nel mio caso Virtual PC) e ricaviamone l’indirizzo IP assegnato per impostarlo nelle proprietà del progetto della nostra applicazione per la connessione al Core Connectivity.

Managed_03

Impostiamo un breakpoint alla prima istruzione ed avviamo l’applicazione; subito dopo il deploy vedremo il debugger funzionare correttamente e permetterci di eseguire l’applicazione step by step direttamente sul target !

Managed_04

Windows Embedded Compact 2013 : supporto per il debugging di un’applicazione .Net Compact Framework 3.9

Siamo giunti alla quarta puntata di questo tutorial che ha come oggetto lo sviluppo e l’utilizzo di un componente proprietario in un’immagine del sistema operativo Windows Embedded Compact 2013. Nel primo post, abbiamo visto come firmare un assembly compilato per il .Net Compact Framework 3.9 in modo da poterlo registrare nella GAC (Gloabal Assembly Cache); per farlo, abbiamo usato l’assembly della libreria M2Mqtt. Nel secondo post, abbiamo realizzato un componente che sia visibile nel catalog items di Platform Builder e che permetta di includere facilmente tale libreria con tutte le impostazioni necessarie per la registrazione nella GAC. Nel terzo post, abbiamo visto come sia possibile distribuire il proprio componente a terze parti e come sia semplice includerlo nel sistema operativo. A questo punto, il passo successivo consiste nel predisporre l’immagine con alcuni strumenti di debug in vista dell’applicazione di esempio nell’ultimo post.

Il framework Core Connectivity

Una delle principali caratteristiche di Windows Embedded Compact sin dalle prime versioni è quella di poter eseguire il debugging delle applicazioni managed (e non) sviluppate con il .Net Compact Framework direttamente sul target device. Tale potenzialità viene fornita attraverso Core Connectivity, ossia un framework di comunicazione che permette di stabilire una connessione con il target device per poter effettuare debugging (oltre ad un’altra serie di funzionalità).

Tale framework è costituito da una serie di file che possiamo trovare sul PC di sviluppo a seguito dell’installazione di Platform Builder nella seguente cartella :

C:\Program Files\Common Files\microsoft shared\Embedded Tools\CoreCon\11.0\Target\wce800 directory (sottocartelle x86 o armv7 in base al target).

In particolare sono :

  • ConmanClient3.exe : avvia il servizio di connessione sul device;
  • Clientshutdown.exe : arresta il servizio di connessione;
  • CMAccept3.exe : disabilita temporaneamente la sicurezza sul device per permettere la connessione dal PC;
  • DeviceagentTransport.dll, EDbgTL.dll, TcpConnectionA.dll : DLL necessarie alla connessione;

Per poter utilizzare tale infrastruttura, è necessario copiare questi file sul target device ed eseguire prima ConmanClient3.exe (per avviare il servizio) e successivamente CMAccept3.exe (per disabilitare la protezione); da questo momento in poi abbiamo 3 minuti per connetterci al target. Per evitare questo timeout e disabilitare la sicurezza sul sistema, è possibile impostare la seguente chiave di registro :

[HKLM\System]
    “CoreConOverrideSecurity”=dword:1

E’ importante ricordarsi di rimuovere questa impostazione nel momento in cui andremo a generare l’immagine per la produzione.

L’inclusione di questo framework nell’immagine del sistema operativo è comparabile all’inclusione di un componente (come visto nei post precedenti) per cui è necessario copiare i file nella release directory (con una custom build action o un file batch), modificare il BIB file (dell’OS Design, BSP o SubProject) e modificare il REG file (se vogliamo aggiungere la chiave che disabilita la sicurezza). Anche in questo caso ci viene in aiuto un componente per Platform Builder già pronto e disponibile online su CodePlex : AutoLaunch for Windows Embedded Compact (CE).

AutoLaunch : includiamo il CoreCon con un click !

AutoLaunch è un componente per Platform Builder, sviluppato da Samuel Phung e David Jones, che permette di includere con un semplice click il framework CoreCon nell’immagine del sistema operativo, occupandosi anche di disabilitare eventualmente la sicurezza con la corrispondente impostazione nel registro di sistema e di avviare anche il servizio di connessione al boot del target device. In questo modo, lo sviluppatore non deve fare assolutamente nulla se non stabilire la connessione del proprio ambiente Visual Studio per avviare il debug della propria applicazione.

Questa è la sua funzionalità principale, il cui scopo primario è però quello di fornire la possibilità di impostare delle applicazioni da lanciare all’avvio anche con un eventuale delay. Infatti, questo componente non contiene esclusivamente files da includere o meno nell’immagine ma è caratterizzato anche da un vero e proprio programma scritto in C++ che esegue l’operazione suddetta.

Come tutti i componenti sviluppati da terze parti per Platform Builder, dopo averlo scaricato dal sito CodePlex è necessario estrarre il suo contenuto nella cartella \WINCE800\3rdParty in modo che esso risulti immediatamente visibile nel catalog items.

AutoLaunch_01

E’ possibile decidere di includere o meno i componenti CoreCon, usando l’item “Autolaunch CoreCon”, in modo che la variabile di ambiente BSP_AUTOLAUNCH_CORECON ad esso associata sia settata ed il BIB file includa i files corrispondenti. Sulla base della medesima variabile di ambiente, il REG file permette di impostare la disabilitazione della sicurezza e l’avvio automatico del servizio di connessione.

AutoLaunch_02

Le ultime due operazioni da fare per avere un’immagine pronta per il debugging sono :

  • disablitare il KITL (Kernel Indipendent Transport Layer) avendo incluso i componenti CoreCon;
  • includere il componente “Application Builder Debugging Support” del catalog items (in CoreOS –> Windows Embedded Compact –> Applications and Services Development –> Diagnostics and Debugging Tools) necessario per utilizzare l’Application Builder (di cui parleremo nell’ultimo post);

A conclusione di questo post, abbiamo tutto il necessario per poter buildare un’immagine che sia predisposta per il deploy ed il debugging di un’applicazione .Net Compact Framework 3.9 che faccia uso del componente M2Mqtt incluso; vedremo come fare proprio nell’ultimo post di questa serie !

Il componente M2Mqtt4CE : un client MQTT da includere nell’immagine di Windows Embedded Compact 2013

Nel post precedente, utilizzando il tool CEComponentWiz abbiamo creato un componente custom che sia visibile nel catalog items del Platform Builder.

Abbiamo utilizzato l’assembly della libreria M2Mqtt compilata per il .Net Compact Framework 3.9 ed abbiamo generato il componente corrispondente che ho reso pubblicamente disponibile su CodePlex con il nome di M2Mqtt4CE !

M2Mqtt4CE : descrizione del componente

Tale componente può essere utile ad un qualsiasi OEM che debba produrre un’immagine del sistema operativo Windows Embedded Compact 2013 e che abbia direttamente a bordo un client MQTT per .Net Compact Framework 3.9. Supponendo di essere l’OEM, possiamo scaricare il pacchetto M2Mqtt4CE da CodePlex ed estrarre il contenuto nella cartella \WINCE800\3rdParty (come descritto nel file ReadMe.txt allegato).

I file principali che ne fanno parte sono :

  • M2Mqtt.dll (contenuto nella cartella Resources) è l’assembly firmato della libreria M2Mqtt che viene incluso nell’immagine e registrato nella GAC;
  • M2Mqtt.bib è il BIB file che stabilisce l’inclusione del file M2Mqtt.dll (sezione FILES) nell’immagine rinominandolo in GAC_M2Mqtt_v3_0_0_1_cneutral_1.dll per la registrazione nella GAC;
  • M2Mqtt.reg contiene le chiavi di registro necessarie per la registrazione nella GAC dell’assembly firmato GAC_M2Mqtt_v3_0_0_1_cneutral_1.dll;

Inoltre, il file postlink.bat, eseguito dal sistema di build, effettua la copia de file M2Mqtt.dll dalla Resources directory nella release directory, per poi essere rinominato in GAC_M2Mqtt_v3_0_0_1_cneutral_1.dll (attraverso il BIB file) in fase di generazione dell’immagine.

Includiamo M2Mqtt nell’immagine

Apriamo un progetto esistente oppure creiamone uno nuovo utilizzando il Wizard di Visual Studio 2012. Al termine del Wizard, aprendo il catalog items di Platform Builder il componente M2Mqtt sarà visibile in Third Party –> Embedded101 per poter essere incluso con un semplice click !

CEComponentWiz_04

Clicchiamo su di esso ed eseguiamo il build dell’immagine senza dimenticarci di includere anche il .Net Compact Framework, poichè la libreria M2Mqtt è di tipo managed.

Ispezione del file NK.bin generato

Non tutti sanno che utilizzando Visual Studio (sin dalle prime versioni del Platform Builder) possiamo aprire il file NK.bin e vederne il contenuto del file system oltre che del registro di sistema.

NK_files

Nella sezione “files” vediamo il file GAC_M2Mqtt_v3_0_0_1_cneutral_1.dll incluso come file nascosto e di sistema.

NK_registry

Nella sezione “Registry” vediamo le impostazioni del registro di sistema necessarie per la corretta registrazione nella GAC (come tutti gli altri assembly del .Net Compact Framework). L’assembly è correttamente firmato con un Public Key Token corrispondente.

Nel prossimo post, parleremo di un altro componente della famiglia Embedded101 attraverso il quale fornire uno dei principali strumenti di debugging in un’immagine del sistema operativo (Core Connectivity), in vista dello sviluppo di un’applicazione di esempio che faccia uso del client MQTT.

Platform Builder ed il .Net Framework 4.5.1 : tutto risolto su Windows Embedded Compact 2013 con l’ultimo update !

In questo post ho parlato di un bug dell’attuale release di Windows Embedded Compact 2013 per il quale il sistema di build non era più in grado di riconoscere il .Net Framework a seguito dell’aggiornamento dalla versione 4.5 alla 4.5.1. Nello stesso post ho anche descritto un possibile workaround per poter continuare ad utilizzare Platform Builder senza problemi nell’attesa di una patch ufficiale da parte di Microsoft.

Con l’aggiornamento relativo a Gennaio 2014 e che potete scaricare qui … il bug è stato risolto !

Se avete utilizzato il mio workaround, vi conviene ripristinare tutto come era prima dal file sources.ce nel percorso C:\WINCE800\public\common\oak\misc (rimuovendo la variabile _DOTNET40ROOT) al ripristino della variabile di sistema PATH.

A seguito del ripristino…eseguite l’aggiornamento e tutto funzionerà come sempre !

Windows Embedded Compact 2013 : creazione di un nuovo componente per il catalog items di Platform Builder

Nel post precedente abbiamo visto come sia possibile firmare un assembly (la mia libreria M2Mqtt) per poterlo includere direttamente in un’immagine del sistema operativo Windows Embedded Compact 2013 e registrarlo nella GAC (Global Assembly Cache). Nel corso di questo post, vedremo come sia possibile realizzare un componente visibile nel catalog items di Platform Builder, attraverso il quale includere la nostra libreria nell’immagine in maniera molto semplice.

Creare un nuovo componente ? Le possibili soluzioni

Durante la generazione di un’immagine del sistema operativo Windows Embedded Compact 2013 per un target device, si pone molto spesso la necessità di aggiungere un nostro componente (un’applicazione, una libreria oppure un qualsiasi altro tipo di file) all’immagine stessa, senza attingere dal catalog items che il Platform Builder ci mette a disposizione, essendo appunto tale componente di nostra proprietà.

Purtroppo, in molti casi, la soluzione più semplice ma anche quella meno “elegante” consiste nel copiare il file da includere nella cartella del nostro OSDesign (solution del sistema operativo) e modificare il corrispondente BIB file per impostarne l’inclusione nell’NK.bin generato. Addirittura, in molti casi si sceglie di definire l’inclusione a livello di BSP e non in termini di singolo OSDesign, influenzando in questo modo tutti i progetti generati a partire dalla medesima BSP. A tutto ciò, dobbiamo aggiungere eventuali modifiche al REG file se il componente incluso prevede delle impostazioni nel registro di sistema ed una altrettanto eventuale modifica al DAT file se è necessario creare dei link al componente al di fuori della cartella \Windows (in cui sono riposti di default tutti i file di sistema). Infine, è necessario aggiungere una custom build action che permetta di copiare il file dalla nostra directory (che sia OSDesign o BSP) nella release directory, per permetterne l’inclusione nell’NK.bin finale.

La soluzione più “elegante” consiste nel creare un SubProject attraverso il Platform Builder ed effettuare tutti i passi suddetti utilizzando i suoi file di configurazione (BIB, REG, DAT, ..) oltre ai file batch per le custom actions. Inoltre, è possibile associare a quest’ultimo un file di catalogo in modo da far comparire il nostro componente nel catalog items e permettere ad uno sviluppatore di terze parti di includerlo banalmente nell’immagine del sistema operativo.

Tutti questi passi risultano ripetitivi e sarebbe utile avere a disposizione un tool che li automatizzasse per noi; questo tool esiste e si chiama “Windows Embedded Compact (CE) Component Wizard” (noto come CEComponentWiz). E’ stato sviluppato da Samuel Phung e David Jones, è disponibile su CodePlex e rende estremamente semplice tutta la procedura di cui abbiamo appena parlato.

Installiamo il CEComponentWiz

Abbiamo a disposizione due modalità di installazione : come tool, accessibile nel menu Tools di Visual Studio 2012, oppre come PB script, accessibile nel menu Tools –> Platform Builder. Nel primo caso, al termine dell’installazione dobbiamo aggiungere manualmente il tool al menu nel modo seguente :

  1. Selezionare “External Tools” dal menu Tools di Visual Studio 2012;
  2. Aggiungere un nuovo tool ed impostare :
    1. il titolo (es. CEComponentWiz)
    2. selezioniamo l’eseguibile all’interno della cartella di installazione;
    3. specifichiamo $(ProjectFileName) $(ProjectDir) come argomento (attenzione allo spazio tra i due parametri);
    4. impostiamo $(TargetDir) come directory iniziale;

In questo modo, il tool sarà visibile nel menu ed attivabile una volta selezionato il progetto del sistema operativo dal Solution Explorer.

CEComponentWiz_01

Nel secondo caso, viene installato un file PB script nella cartella PBScripts nei Documenti che ha il compito di lanciare il CEComponentWiz attraverso Visual Studio 2012. Per attivare questo script è necessario avviarlo una prima volta attraverso il menu Tools –> Platform Builder –> Configure Scripts. Una volta eseguito, esso sarà disponibile nel medesimo menu come script attivo da poter eseguire.

CEComponentWiz_02

Creazione del componente M2Mqtt

Per poter utilizzare il tool CEComponentWiz è necessario aprire un progetto OSDesign in Visual Studio 2012 e successivamente lanciare il tool stesso. Inoltre, dobbiamo predisporre il materiale che includeremo attraverso il componente generato. In questo caso, dobbiamo procurarci l’assembly della M2Mqtt library compilato per il .Net Compact Framework 3.9.

Avviamo il tool ed attraverso il menu GetContent –> Modules, selezioniamo il file da includere (in questo caso M2Mqtt.dll); nel caso di un assembly per il .Net Compact Framework 3.9 dobbiamo accertarci che esso sia incluso nella sezione FILES del BIB file e che la flag “C” (compressed) sia abilitata. Dovendo registrare l’assembly nella GAC è necessario modificarne il nome del modo seguente :

GAC_M2Mqtt_v3_0_0_1_cneutral_1.dll

Inoltre, utilizzando CEComponentWiz abbiamo la possibilità di impostare le chiavi di registro necessarie alla registrazione nella GAC che sono le seguenti :

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETCompactFramework\Installer\Assemblies\ROM]
    "M2Mqtt, Version=3.0.0.1, Culture=neutral, PublicKeyToken=974d508d5b9f76a5"=multi_sz:"\\windows\\GAC_M2Mqtt_v3_0_0_1_cneutral_1.dll","M2Mqtt.dll"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETCompactFramework\Installer\Assemblies\Global]
    "M2Mqtt, Version=3.0.0.1, Culture=neutral, PublicKeyToken=974d508d5b9f76a5"=multi_sz:"\\windows\\GAC_M2Mqtt_v3_0_0_1_cneutral_1.dll","M2Mqtt.dll"

Creiamo un file .reg contenente le chiavi suddette (es. M2Mqtt_registry.reg) ed aggiungiamo questo file attraverso il menu GetContent –> Registry Entries.

CEComponentWiz_03

Attraverso il menu Generate Component Project –> Component Details è possibile impostare il nome del progetto, una descrizione, un commento ed il produttore. Inoltre, attraverso la voce OS Version dobbiamo impostare 8.00 nel caso di Windows Embedded Compact 2013. Cliccando su Generate Development Component, il tool crea un subproject all’interno della cartella dell’OS Design corrente con tutti i file di configurazione necessari.

A questo punto possiamo aggiungere manualmente (con Add exisisting subproject) il subproject al nostro OS Design ma il tool ci fornisce l’ulteriore funzionalità di creazione di un componente nella directory WINCE800\3rdParty. In questo modo, se visualizziamo il catalog items ed eseguiamo il refresh, avremmo a disposizione il nostro componente da poter includere con un semplice click !

CEComponentWiz_04

Con questo post siamo riusciti a realizzare un componente proprietario per il Platform Builder che possiamo distribuire a chiunque voglia includere nella propria immagine del sistema operativo la libreria M2Mqtt, in modo da averla onboard senza la necessità di doverla distribuire con la propria applicazione.

Più Post Pagina seguente »