blogs.ASPItalia.com

Mono e Framework... un po' di semplici benchmark parte seconda

Andrea Zani — Mon, 16 Nov 2009 20:45:00 GMT

Poco pi� di un anno fa avevo scritto un blog dove avevo confrontato le prestazioni di una windows forms scritta in .net su una macchina con Windows XP e una macchina Linux con la versione 1.9 di mono. In questi mesi Mono ha raggiunto la versione 2.4 e gode di ottima salute malgrado ci siano i soliti estremisti che solo all'idea di una tecnologia portata dal mondo Microsoft stanno male. Anche se sempre un paio di versioni indietro da ci� che il Framework offre su sistemi operativi Microsoft, siamo ormai giunti anche al supporto di Linq, di cui potrei parlare in un blog futuro sempre se ne avr� voglia. Per questo luned� sera mi accontenter� di rifare lo stesso test di un anno fa con l'ultima versione di Mono che gira sull'ultima versione di Ubuntu (9.10) e sempre sulla stessa macchina. Ecco il risultato della piccola applicazione la cui descrizione delle operazioni che esegue ho spiegato nel blog prima citato:

Stupito. Per quanto pu� valere questo banale test nel calcolo degli interi e dei doublele prestazioni sono migliorate nettamente, ma anche a confronto della versione originale del Framework che gira su Windows:

	Integer	Double	Xml 1	Xml 2
Windows .net	453,125s	1859,375s	46,875s	4640,625s
Mono 1.9	499,71s	2362.398s	259,891s	26959,493s
Mono 2.4	286,46s	1314,403	475,253	23604,915

Grande velocit� nella trattazione dei numeri ma nella gestione dei file e xml fa ancora parecchio schifo.

Tags: .NET Framework, Mono

Continua a leggere Mono e Framework... un po' di semplici benchmark parte seconda.

Moonlight - Silverlight 1-2

Andrea Zani — Wed, 21 Jan 2009 08:27:00 GMT

Da scoprire a installare Moonlight 1.0 � passato un attimo. Installazione veloce che richiede solo il riavvio di Firefox come ogni suo plug-in. L'inizio dei test avviene qualche minuto dopo. Innanzitutto: Moonlight 1.0 � la versione 1 di Silverlight! Per vedere le applicazioni scritte in Silverlight 2 si dovr� aspettare la versione 2.0 di Moonlight.

Le prove. Dai miei test sulle applicazioni scritte in Silverlight 1, solo il ~60% gira senza problemi. Mi ha sorpreso vedere filmati girare senza problemi e altre molto pi� semplici visualizzare solo un rettangolo grigio e niente altro.

Quando sar� disponibile la versione 2.0? Qui le risposte.

Tags: .NET Framework, Mono, Silverlight, XAML

Continua a leggere Moonlight - Silverlight 1-2.

Mono e Framework... un po' di semplici benchmark

Andrea Zani — Tue, 28 Oct 2008 08:29:50 GMT

"Ma prestazionalmente, sulla stessa macchina, quant'� la differenza tra un'applicazione che gira sul Framework e sistema operativo Microsoft e la stessa su Linux con Mono?"

Questa era una richiesta che mi era stata fatta parecchio tempo fa, ma per questione di voglia o altro non l'avevo mai fatta. Allora ho scritto una semplice windows forms che facesse delle operazioni ripetute su questi semplici scenari:

Calcolo con interi: banale calcolo con soli numeri interi.
Calcolo con decimal: come sopra, ma con l'uso dei decimali.
Lettura completa di un documento xml da 300KB e 44.000 nodi, con il SelectNodes, nodo per nodo.
Apertura ripetuta dello stesso documento xml ripetutamente con ricerca di nodi all'interno dello stesso.

Innanzitutto vediamo l'applicazione in esecuzione:

E su Linux con Mono:

Riassumendo i risultati in una tabella:

	Integer	Double	Xml 1	Xml 2
Windows .net	453,125s	1859,375s	46,875s	4640,625s
Mono	499,71s	2362.398s	259,891s	26959,493s

NB:

La piccola applicazione � stata scritta con Visual Studio 2008 per il Framework 2.0.
Il computer su cui girava Mono aveva Ubuntu 8.10 RC.
Ho potuto usare solo la versione 1.9 di Mono e non la nuova 2.0, ma purtroppo non potevo testare la nuova versione sul computer a disposizione.
Notare le piccole imperfezioni grafiche della versione Mono, teoricamente risolte con la nuova versione.

Tags: .NET Framework, Mono

Continua a leggere Mono e Framework... un po' di semplici benchmark.

GTK, giusta crocevia tra piattaforme?

Andrea Zani — Sun, 26 Oct 2008 12:57:50 GMT

Non ho mai fatto segreto della mia passione per Mono, porting del Framework .Net su sistemi operativi non Microsoft. Passi da gigante sono stati fatti per la compatibilit� delle stesse applicazioni su sistemi operativi differenti, soprattutto per applicazioni desktop (sono fondamentalmente contro all'utilizzo di questo porting per webapplication, visto che il risparmio dovuto ad hosting e licenze dei sistemi operativi sia ridicolo di fronte allo sforzo per la realizzazione di web application che girino perfettamente con Mono - ma questo � assolutamente IMHO!).

Da qualche giorno � uscita la versione 2.0 di Mono. E' aumentata notevolmente la compatibilit� con le applicazini scritte con il Framework nativo della Microsoft. Ora � possibile lanciare moltissime applicazioni windows forms su Linux con Mono senza trovare grosse differenze e problematiche nell'uso dell'interfaccia grafica (cosa che avveniva in modo pesante con la versione 1.2 e, in modo minore, con la 1.9.1).

Nel poco tempo che riesco a dedicare a Mono per miei test, ho trovato ideale l'utilizzo di una libreria esterna per la creazione e l'utilizzo delle interfacce grafiche, compatibile con entrambi i mondi, Windows e Linux. E' il progetto Gtk#, libreria che permette l'utilizzo di Gtk+ che, ricordo, � la libreria grafica utilizzata dal Desktop environment, Gnome. Inoltre � utilizzata gi� con successo da molti altri programmi multi piattaforma, come Pidgin.

Il suo utilizzo in applicazioni .Net su sistemi operativi Linux non necessita di alcuno sforzo visto che nel caso di Gnome � gi� installata la libreria Gtk, nel caso di altri Desktop environment - Kde - � sufficiente installare tale libreria. Installazione necessaria anche sotto Windows da questo link da dove si devono scaricare sia la libreria Gtk+, sia Glade, e infine la Gtk#.

La costruzione dell'interfacce grafica � semplice, grazie a programmi appositi, come Glade (programma scaricato prima), che permette la creazione di interfacce grafiche in modo molto simile a Visual Studio. L'output di questo programma � un xml che, incluso nel nostro progetto con Visual Studio definito come "Embedded Resource" utilizzeremo in questo modo:

public GtkApp(string []args)
{
Application.Init();
Glade.XML gxml = new Glade.XML (null, "googleSearch.googlesearch.glade",
"mainWindow", null);
gxml.Autoconnect (this);
mainWindow.DeleteEvent+=new DeleteEventHandler(mainWindow_DeleteEvent);
btnSearch.Clicked+=new EventHandler(btnSearch_Clicked);
btnClear.Clicked+=new EventHandler(btnClear_Clicked);
Application.Run();
}

Un esempio completo (da cui ho preso questa porzione di codice) lo si trova in questa pagina di CodeProject. Dopo aver caricato l'interfaccia grafica si connette da codice gli eventi agli oggetti come i button all'interno dell'interfaccia grafica. Tutto fatto.

Abbiamo a disposizione altre interfacce grafiche comuni tra i sistemi operativi, come la famosa libreria wxwidgets e il suo porting in .Net, wxwidgets.net. Potente flessibile, ma ha grossi problemi di stabilit� almeno sotto windows dove crolla spesso e volentieri in errori inspiegabili - almeno per me.

Tags: Mono

Continua a leggere GTK, giusta crocevia tra piattaforme?.

Mono e Remoting: come scambiare informazioni tra Windows e Linux

Andrea Zani — Fri, 11 Jul 2008 18:44:31 GMT

In un blog precedente avevo spiegato come creare un servizio con C# e Mono per macchine Linux. Oggi voglio complicare un po' le cose, perch� l'obbiettivo a cui voglio giungere � lo scambio di informazioni tra i due mondi.

La prima soluzione che potrebbe venire in mente � l'utilizzo dei web services. Subito per� nasce un problema di base: per poterli utilizzare dobbiamo avere un web server che gira sulla macchina, e questo non � sempre una buona soluzione perch� necessit� di installazioni e sistemi operativi che consentono questa operazione. Nel mondo Windows � necessario avere almeno Windows Xp Professional oppure Vista. Con qualsiasi distribuzione Linux dobbiamo installare Apache e il modulo apposito perch� possano essere elaborate le pagine asp.net. Ne vale la pena? No, perch� il mondo .Net permette un mezzo pi� potente per lo scambio di dati tra ambienti in cui gira il Framework: il Remoting.

Quei quattro gatti che mi conoscono, sanno la mia passione per il Remoting fin dalla versione 1.1 del Framework. Questa tecnologia permette lo scambio di oggetti tra applicativi scritti in .Net senza la necessit� di web server, inoltre possiamo utilizzare la serializzazione binaria per la trasmissione di dati molto pi� prestazionale che la tradizionale SOAP via HTTP (anche se con il Remoting possiamo utilizzare sia la serializzazione SOAP, sia il trasferimento con il protocollo HTTP). Dal Framework 3.0 � presente la tecnologia WCF, molto pi� potente, ma il mondo Mono � ancora indietro e l'implementazione di WCF e delle novit� presenti dal Framework 3.0 (nome in codice Olive sotto Mono) sono ancora abbastanza indietro.

Un articolo che confrontava i due mondi - Remoting vs web services - lo potete trovare qui. Per spiegare meglio la soluzione proposta in questo blog, ho scritto un banale progetto con MonoDevelop che � possibile scaricare dal link a fondo pagina. Questo piccolo progetto ripropone quanto gi� detto nel blog riguardante la creazione di servizi con Mono. Per questa occasione ho aggiunto al servizio la possibilit� di richiamare una funzione all'interno di una classe direttamente grazie al Remoting.

Innanzitutto, il file allegato presenta tre progetti:

Servizio che attende le chiamate via Remoting.
Client che richiama la funzione via Remoting al servizio.
Classe con l'interfaccia per lo scambio di informazioni.

Il progetto con l'interfaccia � una banale classe con questo codice:

using System;
public interface IRequestInformation
{
string GetNameAndDateTime(string name);
}

Molto banale: � una funzione che accetta come parametro una stringa e ritorna un'altra stringa. Ora nel servizio dobbiamo esporre questa interfaccia con una classe all'interno del servizio. Nulla di complesso:

private void _MainLoop ()
{
TcpChannel channel = new TcpChannel(1981);
ChannelServices.RegisterChannel(channel,false);
RemotingConfiguration.RegisterWellKnownServiceType(
typeof(Information),
"RemotingMessage",WellKnownObjectMode.SingleCall);
MainClass.WriteLog(ServiceName, "Remoting started...");
while (!stopThread)
Thread.Sleep (2000);
}

_MainLoop � la funzione che � possibile trovare spiegata nel blog precedente. In quell'esempio era presente solo il ciclo while, ora � stato aggiunto il codice per l'attesa di chiamate dalla porta Tcp 1981 della classe "Information":

namespace service1
{
public class Information:MarshalByRefObject, IRequestInformation
{
public Information()
{
}
public string GetNameAndDateTime (string name)
{
MainClass.WriteLog("Remoting", "received: "+name); // scrive log
return string.Format("{0}: {1}",name, DateTime.Now);
}
}
}

Questa classe espone l'interfaccia IRequestInformation e il metodo GetNameAndDateTime. Siccome mi manca la fantasia non faccio altro che tornare una stringa contenente il name passato insieme alla data e ora attuale.

Il progetto client allegato � una console application che richiama via remoting la funzione presente nel servizio:

using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;

namespace client
{
class MainClass
{
public static void Main(string[] args)
{
try
{
string name="io"; // Stringa di default se non vengono passati parametri
if (args.Length>0) name=args[0];
IRequestInformation remot;
string location = "tcp://192.168.0.7:1981/RemotingMessage";
remot = (IRequestInformation)Activator.GetObject(
typeof(IRequestInformation), location);
Console.WriteLine(remot.GetNameAndDateTime(name));
}
catch (RemotingException)
{
Console.WriteLine("Impossibile comunicare con il server");
}
}
}
}

Anche qui viene usato l'interfaccia per la creazione automatica per l'utilizzo della classe presente nel servizio. Il Framework penser� al posto nostro alla creazione di una classe proxy per la serializzazione binaria e la trasmissione.

Se si � seguito il blog precedente e il servizio gira sulla macchina (sia che si tratti di Windows che Linux), possiamo richiamare il servizio direttamente dall'eseguibile client:

Questo anche da altre macchine Linux con Mono:

In entrambi i casi il servizio ha risposta ritornando correttamente la stringa passata con la data e l'ora della richiesta. Inoltre, il nostro servizio � in grado di loggare le richieste. Vediamo che cosa ha memorizzato:

Il codice presente nell'allegato ha l'ip e la porta memorizzati direttamente nel codice, per modificarli � necessario ricompilare i progetti. Potevo configurare il Remoting con il file di configurazione del progetto, lo so, ma non ne avevo voglia. Ma se volete provarlo o avete questa strada o fate in modo che il servizio sia memorizzato da una macchina con ip 192.168.0.7.

Una piccola divagazione a margine: come detto nel blog precedente i test sono stati fatti su una macchina con Ubuntu. A parte la versione vecchia di Mono presente nei repository di questa distribuzione, ho scoperto un'altra anomalia. Con l'esempio presente che comunica con porte TCP, mi aspettavo di dover configurare il firewall, proprio come Windows richiede. Con Ubuntu non ho avuto alcun problema. I pacchetti sono passati senza problemi. Dopo una piccola ricerca scopro che Ubuntu ha s� il firewall attivo, ma permette il passaggio indiscrimanto da qualsiasi porta! La pi� famosa, e forse utilizzata, distribuzione Linux ha un firewall pressocch� inutilizzato! La cosa mi ha sorpreso dato che, per esempio, OpenSuse ha il suo bel firewall attivo... Roba da Windows 2000... per fortuna almeno non ha gli stessi problemi di sicurezza.

Dimenticavo: l'allegato � possibile scaricarlo da questo link. La piadina che ho mangiato a cena ce l'ho ancora sullo stomaco. Questa � un'altra divagazione.

Tags: Mono

Continua a leggere Mono e Remoting: come scambiare informazioni tra Windows e Linux.

Servizi in C# su macchine Linux con Mono

Andrea Zani — Sun, 06 Jul 2008 19:05:00 GMT

Pochi giorni fa ho dovuto rifarmi una macchina su cui girava OpenSuse (la distribuzione che preferisco),�ed ho deciso di installare la nuova versione di Ubuntu 8.04 per curiosit� visto che l'ultima versione provata di Ubuntu era la 7.04 e volevo provare con mano l'evoluzione avvenuta in questi dodici mesi.

La prima delusione l'ho avuta nel constatare che la versione presente nei repository�di Mono � la 1.2.6, mentre l'ultima release � la 1.9.1. Non mi pongo problemi, e visto che dovevo installare un servizio per... ehi, un momento, non sono obbligato a scrivere nel dettaglio i fatti miei! Riprendo: dovendo installare un servizio scritto in C# su questa macchina installo mono e mono-service2 dai repository di Ubuntu. mono-service2 � un tool che permette la gestione dei servizi scritti per Mono sotto Linux.

Per informazione riporto un pubblico esempio di un servizio scritto in C#�che pu� girare sia sotto Windows che Linux. Il codice seguente � possibile compilarlo�Visual Studio, da linea di comando sotto Linux con Mono o con MonoDevelop, e pu� essere testato anche come console application:

// Main.cs created with MonoDevelop // User: az using System; using System.Collections; using System.ComponentModel; using System.Diagnostics; using System.ServiceProcess; using System.IO; using System.Configuration.Install; using System.Threading; namespace service1 { �class MainClass �{ ��private const string LogFile = "TestService.log"; ��// The main entry point for the process ��static void Main() ��{ ��Write2Log(null, "Main starting"); ��System.ServiceProcess.ServiceBase[] ServicesToRun; ��ServicesToRun = new System.ServiceProcess.ServiceBase[] { new TestService("TestService1")}; ��System.ServiceProcess.ServiceBase.Run(ServicesToRun); ��Write2Log(null, "Main ended"); ��} ��public static void Write2Log(string category, string message) ��{ ��using (StreamWriter w = new StreamWriter(LogFile, true, System.Text.Encoding.UTF8) ) ��{ ��if ( category != null ) ��w.WriteLine(DateTime.Now.ToString() + " " + category + " - " + message); ��else ��w.WriteLine(DateTime.Now.ToString() + " " + message); ��} ��} �} �public class TestService : System.ServiceProcess.ServiceBase �{ ��private Thread mainThread = null; ��private bool stopThread = false; ��public TestService(string name) ��{ ��this.ServiceName = name; ��this.CanPauseAndContinue = true; ��} ��protected override void Dispose( bool disposing ) ��{ ��MainClass.Write2Log(ServiceName, "Dispose"); ��base.Dispose( disposing ); ��} ��protected override void OnStart(string[] args) ��{ ��MainClass.Write2Log(ServiceName, "Starting Service...");�� mainThread = new Thread (new ThreadStart (_MainLoop)); ��stopThread = false; ��mainThread.Start (); ��} ��protected override void OnStop() ��{ ��MainClass.Write2Log(ServiceName, "Stopping Service..."); ��if (mainThread != null) { ��stopThread = true; ��mainThread.Join (); ��mainThread = null; ��} ��} ��protected override void OnPause() ��{ ��MainClass.Write2Log(ServiceName, "Pausing Service..."); ��} ��protected override void OnContinue() ��{ ��MainClass.Write2Log(ServiceName, "Continuing Service..."); ��} ��private void _MainLoop () ��{ ��while (!stopThread) ��Thread.Sleep (2000); ��} �} �///


�/// This class allows easy installation of this service on Windows.
�///


�[RunInstaller(true)]
�public class ProjectInstaller : System.Configuration.Install.Installer
�{
��private System.ServiceProcess.ServiceProcessInstaller serviceProcessInstaller1;
��private System.ServiceProcess.ServiceInstaller serviceInstaller1;
��private System.ComponentModel.Container components = null;

��public ProjectInstaller()
��{
���// This call is required by the Designer.
���InitializeComponent();
��}

��/// 
��/// Clean up any resources being used.
��/// 

��protected override void Dispose( bool disposing )
��{
���if( disposing )
���{
����if(components != null)
����{
�����components.Dispose();
����}
���}
���base.Dispose( disposing );
��}

��#region Component Designer generated code
��/// 
��/// Required method for Designer support - do not modify
��/// the contents of this method with the code editor.
��/// 

��private void InitializeComponent()
��{
���this.serviceProcessInstaller1 = new System.ServiceProcess.ServiceProcessInstaller();
���this.serviceInstaller1 = new System.ServiceProcess.ServiceInstaller();
���//this.serviceInstaller2 = new System.ServiceProcess.ServiceInstaller();
���// 
���// serviceProcessInstaller1
���// 
���this.serviceProcessInstaller1.Password = null;
���this.serviceProcessInstaller1.Username = null;
���// 
���// serviceInstaller1
���// 
���this.serviceInstaller1.DisplayName = "Test Service 1";
���this.serviceInstaller1.ServiceName = "TestService1";
���// 
���// ProjectInstaller
���// 
���this.Installers.AddRange(new System.Configuration.Install.Installer[] {
������ this.serviceProcessInstaller1,
������ this.serviceInstaller1
�����});
��}
��#endregion
�}
}

Questo servizio � solo un test: scrive in un file di testo quando il servizio viene avviato e quando viene fermato. Una volta testato e confermato il suo funzionamento corretto, provo ad installarlo come servizio sotto Ubuntu con mono-service2. L'help di questo comando � molto chiaro:

az:~$ mono-service2 
You must specify at least the assembly name

Usage is: /usr/bin/mono-service2 [options] service

��� -d:�������� Working directory
��� -l:�������� Lock file (default is /tmp/.lock)
��� -m:������ Name to show in syslog
��� -n:����� Name of service to start (default is first defined)
��� --debug��������������� Do not send to background nor redirect input/output
��� --no-daemon����������� Do not send to background nor redirect input/output

Controlling the service:

��� kill -USR1 `cat `��� Pausing service
��� kill -USR2 `cat `��� Continuing service
��� kill `cat `��������� Ending service

az:~$

Ok, vado nella directory dove � presente il codice compilato del servizio e lancio il comando con l'opzione della working directory:

sudo mono-service2 -d:/home/az/project/service1/service1/bin/Debug/� /home/az/project/service1/service1/bin/Debug/service1.exe

Ma ottengo un non precisato errore: "41: Syntax error: Bad fd number". Una veloce ricerca e trovo che � un bug noto sotto Ubuntu. Sempre a quel link � presente la correzione da fare, anche se un modo migliore per risolvere ogni problema lo spiegher� dopo.

Finalmente tutto funziona. Ora per fare le cose per bene dobbiamo fare in modo che tale servizio sia avviato in automatico all'avvio della macchina, senza nessuna autenticazione dell'utente. Per ottenere questo � necessario creare uno script apposito in "/etc/init.d/". Lo script, che chiamer� "azservice" � il seguente:

#!/bin/sh
# Start/stop the az daemon.
#
### BEGIN INIT INFO
# Provides:��������� service1
# Short-Description: Test di AZ
# Description:������ Service write in C# for mono and linux world
### END INIT INFO

. /lib/lsb/init-functions

case "$1" in
start)�log_daemon_msg "Starting test service az" "az-service1"
�mono-service2 -d:/home/az/project/service1/service1/bin/Debug/� /home/az/project/service1/service1/bin/Debug/service1.exe
�;;
stop)�log_daemon_msg "Stopping test service az" "az-service1"
�kill `cat /tmp/service1.exe.lock`
������� ;;
restart) log_daemon_msg "Restarting test service az" "az-service1"
�kill `cat /tmp/service1.exe.lock`
�mono-service2 -d:/home/az/project/service1/service1/bin/Debug/� /home/az/project/service1/service1/bin/Debug/service1.exe
������� ;;
reload|force-reload) log_daemon_msg "Reloading test service az" "az-service1"
�kill `cat /tmp/service1.exe.lock`
�mono-service2 -d:/home/az/project/service1/service1/bin/Debug/� /home/az/project/service1/service1/bin/Debug/service1.exe
������� ;;
*)�log_action_msg "Usage: /etc/init.d/azservice {start|stop|restart|reload|force-reload}"
������� exit 2
������� ;;
esac
exit 0

Dipendentemente dall'opzione passata (start, stop, restart, reload, force-reload), viene invocato in comando mono-service2 con le opzioni necessarie per avviare, fermare o riavviare il servizio:

sudo /etc/init.d/azservice start
sudo /etc/init.d/azservice stop

Per essere richiamato con il precedente modo dobbiamo aggiungere a questo file il flag "avviabile":

sudo chmod +x� /etc/init.d/azservice

Trovo interessante il modo utilizzato per fermare un servizio. Prendendo la linea di codice utilizzata si pu� notare una strana sintassi per chi non � avvezzo a Linux:

kill `cat /tmp/service1.exe.lock`

cat /tmp/service1.exe.lock visualizza normalmente a video il contenuto del file (in questo caso il numero di processo del servizio). Racchiuso tra quegli apici, prende l'output del comando e lo invia a kill che fermer� il processo del servizio.

Per completare il tutto dobbiamo inviare un ultimo comando. Linux ha vari level di avvio. Ognuno di essi si contraddistingue per l'avvio di n�servizi.�Maggiori informazioni a riguardo si possono trovare qui. Per fare in modo che il nostro servizio sia collegato a questi level, dobbiamo scrivere il comando:

sudo update-rc.d azservice defaults

Dove azservice � il nome del file che abbiamo creato in /etc/init.d/. Il nostro lavoro � finito. Ad ogni avvio il servizio verr� richiamato. Un piccolo avvertimento: questo servizio ha normalmente accesso a tutti i file e un'operazione sbagliata pu� creare danni irreversibili sulla macchina (ipottizzando che debba cancellare dei file presenti in una directory, un comando come rm -rf * pu� avere effetti indesiderati se richiamata nella directory root della macchina ;)).

Ubuntu presenta un tool "Servizi" che permette la gestione dei servizi sulla macchina. Si pu� notare come quello appena creato non sia presente nella lista. Non volendo investigare oltre per scoprire il perch�, ho utilizzato di un altro strumento pi� potente, "BUM" (Boot-up manager) installabile dai repository, in grado di gestire anche quello che ho appena creato, come si vede in figura:

Nel caso di Ubuntu consiglio anche l'upgrade immediato all'ultima versione 1.9.1 di Mono. Per ottenere questo � sufficiente aggiungere il repository di Mono, come � spiegato qui, che risolve anche il bug prima citato di mono-service2.

Tags: .NET Framework, Mono

Continua a leggere Servizi in C# su macchine Linux con Mono.