wceTip

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.

6175.SDK_thumb_2576DA7E

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.

4431.AppBuilder_01_thumb_59AD9475

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.

4011.Managed_01_thumb_4F7E8AB9

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.

8244.Managed_02_thumb_6E578F48

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.

static void Main(string[] args)
{
 Console.WriteLine("Welcome to C# on Windows Embedded Systems");

 MqttClient client = new MqttClient(IPAddress.Parse("192.168.1.4"));
 client.Connect("netcfclient");

 Random random = new Random();
 while (true)
 {
 int data = random.Next(10);
 client.Publish("/data", Encoding.ASCII.GetBytes(data.ToString()));
 Thread.Sleep(1000);
 }
}

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.

5100.Managed_03_thumb_62582FC5

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 !

1200.Managed_04_thumb_4D693E03

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.

0285.AutoLaunch_01_thumb_210BE842

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.

1768.AutoLaunch_02_thumb_40511FC6

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 !

5466.CEComponentWiz_04_thumb_4C3A99A0

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.

0005.NK_files_thumb_7C647514

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

4621.NK_registry_thumb_62903EE5

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.

0028.CEComponentWiz_01_thumb_34956CA5

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.

4152.CEComponentWiz_02_thumb_5DA00BA1

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.

0028.CEComponentWiz_03_thumb_0DC9E716

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 !

6283.CEComponentWiz_04_thumb_063E77A9

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.

Windows Embedded Compact 2013 : firmiamo un assembly per il .Net Compact Framework 3.9 da includere nella GAC

Con questo post, inizia un breve tutorial sull’utilizzo di una libreria proprietaria (da noi sviluppata con .Net Compact Framework 3.9) su Windows Embedded Compact 2013, dalla firma dell’assembly (per la registrazione nella GAC) fino al progetto di esempio, passando per la realizzazione di un componente esposto dal Platform Builder (nel catalog items) e da poter includere banalmente nell’immagine del sistema operativo.

In particolare vedremo :

  1. Come eseguire la firma di un assembly;
  2. Creazione di un componente proprietario per il catalog items di Platform Builder;
  3. Distribuzione ed inclusione del componente nell’immagine del sistema operativo;
  4. Supporto per il debugging dell’applicazione che utilizzerà il componente;
  5. Realizzazione di una semplice applicazione di esempio;

Prenderò come riferimento il mio progetto M2Mqtt (MQTT Client library for .Net), supponendo che sia esso il componente da voler includere nell’immagine, in modo che terze parti possano sviluppare un’applicazione che lo utilizzi avendolo già onboard su un target device con Windows Embedded Compact 2013 e .Net Compact Framework 3.9.

La firma : GAC, Public Key Token e Strong Name

Molto spesso si pone la necessità di includere un proprio assembly (magari una libreria da noi sviluppata) direttamente in un’immagine di Windows Embedded Compact, così come viene incluso il .Net Compact Framework grazie al Platform Builder (utilizzando semplicemente il catalog items). In questo modo, la DLL si troverà nella cartella \Windows del target device (insieme a tutti gli assembly del framework) e sarà utilizzabile da applicazione terze parti solo registrandola nella GAC (Global Assembly Cache).

Nel caso del .Net Compact Framework, per eseguire la verifica dell’assembly al suo caricamento dalla GAC, è necessario che esso sia firmato ed abbia un Public Key Token associato. Il Public Key Token è un hash a 64 bit della chiave pubblica relativa alla chiave privata utilizzata per firmare l’assembly. E’ utile per rendere un assembly univoco in modo che due assembly con lo stesso nome vengano considerati distinti (ecco perché si parla di Strong Name). Considerando come riferimento la mia libreria M2Mqtt per il .Net Compact Framework 3.9, vediamo quali sono i passaggi necessari per la firma dell’assembly corrispondente.

Usiamo lo Strong Name Tool

In primo luogo è necessario generare una coppia di chiavi privata/pubblica e per questa operazione possiamo utilizzare lo Strong Name Tool (sn.exe) fornito con Visual Studio. Lanciamo il “Developer Command Prompt for VS2012” ed eseguiamo il seguente comando :

sn –k M2Mqtt.snk

Firmiamo l’assembly

Il passo successivo è quello di utilizzare questo file .snk per la firma dell’assembly in modo da generare un Public Key Token corrispondente. Generalmente, un progetto basato su .Net Framework ha la tab “Signing” nella finestra delle “Properties” in cui è possibile selezionare il file.

8712.01_thumb_3FCD4E6E

Nel caso di un progetto per il .Net Compact Framework 3.9, questa tab non è disponibile ma è necessario intervenire sul file AssemblyInfo.cs specificando al suo interno la linea seguente :

[assembly:AssemblyKeyFileAttribute(“M2Mqtt.snk”)]

Il file .snk va copiato nella stessa cartella in cui si trova quello di progetto (.csproj).

Attraverso questa impostazione, al termine della compilazione avremo un assembly firmato (in questo caso M2Mqtt.dll) che possiamo ispezionare utilizzando un tool come il Reflector della RedGate.

1374.02_thumb_1826D244

Abbiamo l’assembly firmato e pronto per essere incluso nell’immagine del sistema operativo. Nel post successivo vedremo come sia possibile realizzazione un componente visibile nel catalog items di Platform Builder che includa il nostro file e tutta la relativa configurazione.

VS2012 e Platform Builder : “fatal error ! Microsoft.NET Framework v4.x must be installed on your machine”

Oggi, preparando un’immagine di Windows Embedded Compact 2013 per una eBox 3310A e per la demo alla Microsoft Embedded Conference 2014 di Febbraio, il sistema operativo Windows 7 (su una macchina virtuale) decide di aggiornare la versione del .Net Framework dalla 4.5 alla 4.5.1.

Riavvio il sistema e riprendo il lavoro ma … il sistema di build di Visual Studio 2012 è impazzito ed il successivo tentativo di compilazione fallisce !!

2235.fatalerror_thumb_01D24A53

Un warning segnala che il .Net Framework 4.5 non è più installato nel sistema ed un ovvio errore fatale indica che la compilazione non può essere eseguita !

Non ho trovato alcuna notizia ufficiale da parte della Microsoft per risolvere questo problema ma ho aggirato il problema nel modo seguente….

In primo luogo apro il file indicato dall’errore fatale, ossia il sources.ce nel percorso C:\WINCE800\public\common\oak\misc, il quale segnala l’errore nel caso in cui la variabile d’ambiente _DOTNET40ROOT risulta vuota.

!IF “$(_DOTNET40ROOT)” == “”
!   ERROR Error: Microsoft.NET Framework v4.x must be installed on your machine.
!ENDIF

In testa al file, imposto questa varibile al percorso del .Net Framework ossia uguale a C:\Windows\Microsoft.NET\Framework\v4.0.30319.

_DOTNET40ROOT=C:\Windows\Microsoft.NET\Framework\v4.0.30319

Questo primo passo mi permette di superare il blocco nella prima fase di SYSGEN ma il build fallisce ancora, in quanto MSBuild ancora “non vede” il .Net Framework. La soluzione più semplice è quella di impostare il percorso del .Net Framework anche nella variabile PATH (attraverso il pannello di controllo).

7610.cp_thumb_60E3F90D

Dopo questa ulteriore passo, il sistema di build ritorna in se e riprende a funzionare correttamente !

Nell’attesa di un intervento ufficiale da parte di Microsoft, spero che questo workaround possa essere utili a quanti come me si sono trovati davanti questo problema.

Platform Builder : compilazione parallela di Windows Embedded Compact su più “core” della CPU

Il sistema di build di Platform Builder è abbastanza complicato ma nello stesso tempo anche estremamente potente. Per poter risparmiare del tempo prezioso durante la compilazione della propria immagine del sistema operativo, è necessario conoscerlo nei minimi dettagli in modo da evitare operazioni inutili. Inoltre, esistono una serie di “trucchi” che ci permettono di renderlo molto più veloce. Tra questi c’è la possibilità di sfruttare la compilazione su più “core” della nostra CPU, considerando che tutti i PC moderni hanno ormai dai 2 “core” in su.

La chiave di questa possibilità è la variabile d’ambiente BUILD_MULTIPROCESSOR, il cui significato può essere interpretato in maniera sbagliata se non si leggesse attentamente la relativa documentazione. Erroneamente, si potrebbe pensare che impostandola a 0, la compilazione su più “core” venga disabilitata e viceversa attivata impostandola ad 1. Non è assolutamente così !

Facendo riferimento alla documentazione su MSDN, impostando il valore a 0, si lascia al sistema di build il compito di rilevare in automatico il numero di “core” della CPU e di utilizzarli tutti per la compilazione creando un opportuno numero di thread; viceversa, un numero da 1 ad N imposta esplicitamente il numero di thread da utilizzare.

Per fortuna, il valore 0 è quello di default, per cui in molti casi non ci dobbiamo preoccupare di modificarlo per avere il massimo delle performance in compilazione. Inoltre, seppure volessimo modificarla, è prevista un’opportuna voce di menu in Visual Studio che troviamo inTools –> Options –> Platform Builder.

Tools

Per evidenziare la differenza, ho utilizzato una macchina virtuale (con Platform Builder per Windows Embedded Compact 2013 installato in Visual Studio 2012) con 4 core. La prima volta ho compilato la mia immagine con BUILD_MULTIPROCESSOR = 1 ed il risultato è una CPU che non viene sfruttata oltre il 50%.

BUILD_MULTIPROCESSOR_1

La seconda volta ho compilato utilizzando BUILD_MULTIPROCESSOR = 0 (default) ed il risultato è una CPU sfruttata fino al 100%.

BUILD_MULTIPROCESSOR_0

In conclusione, è fondamentale conoscere una serie di impostazioni (talvolta nascoste) che il Platform Builder ci mette a disposizione per poter eseguire in tempi sempre più rapidi le compilazioni delle nostre immagini !

wceTip #1 : Conoscere i valori di tutte le environment variables

Il sistema di build di un’immagine di Windows CE 6.0 si basa su una serie di tool (tipicamente file batch) che eseguono delle azioni sulla base di un insieme di environment variables settate automaticamente quando aggiungiamo i catalog items, BSP drivers e quant’altro oppure che possiamo settare manualmente.

Per conoscerle tutte con i relativi valori, è possibile utilizzare il comando set aprendo il prompt del Platform Builder (in VS2005) alla voce di menu :

Build –> Open Release Directory in Build Window

Di seguito uno screenshot …

7762.wce_set_cmd_14E8C845