2009-11-24 3 views
14

Quali sono le migliori pratiche per scrivere codice che può essere compilato in modo incrociato su .NET (Windows) e Mono (Linux)? Sebbene io abbia molta familiarità con .NET, non sono così esperto in Mono e tutti i suoi trucchi. Qualcuno ha visto un buon post sul blog o un best practice su questo, che non sono stato in grado di trovare? Vorrei attenermi alle funzionalità di livello C# 3.0.Best practice per la compilazione incrociata .NET/MONO

Le cose che mi riguardano sono prima di tutto Interop, dato che dovrei chiamare un codice nativo. Successivo sarebbe il modo migliore per gestire spazi dei nomi come Mono.XXX. Dovrei usare un sacco di #if? Isolare il codice in assiemi per piattaforma?

Qualsiasi suggerimento riguardante l'architettura e il design sarebbe molto apprezzato! Se hai avuto esperienza nella compilazione incrociata per Linux/Mono in Visual Studio (qualsiasi versione), sarei interessato anche a questo.

+0

La compilazione incrociata è la frase sbagliata, la si compila una sola volta e quindi la si utilizza su entrambe le piattaforme. – trampster

+0

Non penso sia corretto, dato che Mono ha un numero di Mono. * Namespace, ecc. Forse in un mondo perfetto? –

+0

Bene, ho creato un'app WinForms senza P/Invoke (sembra facile ma è difficile evitare P/Invoke) e ha funzionato perfettamente su Linux, lo stesso.l'assemblaggio exe VS2010 ha prodotto e ha persino utilizzato le nuove funzionalità di .NET 4. –

risposta

7

I problemi più grandi stanno attaccando alle API Mono-supportati. L'utilizzo del supporto Visual Studio Integration in Mono può essere di grande aiuto in questo modo, dal momento che puoi puntare a Mono per tutto il tempo, su tutte le piattaforme.

Per le vostre domande specifiche:

1) Interop - È necessario attenersi a P/Invoke. Prova a isolare questo in assembly separati specifici della piattaforma. Questo porta a 2:

2) Utilizzare #if - Eviterei questo, e preferisco usare un modello di estensibilità. Mono supporta lo Managed Extensibility Framework, che fornisce un buon modo per "inserire" il codice specifico della piattaforma in fase di runtime.

+0

Grazie per il puntatore al modello di estensibilità. Mostra che è un'anteprima, non un prodotto di spedizione. Quali sono le possibilità che le implementazioni .net e mono siano sincronizzate prima che il prodotto sia finalizzato? Il plugin di integrazione di Visual Studio sarà sicuramente di aiuto, grazie. –

+0

MEF è open source, quindi non mi preoccuperei troppo. Farà parte di .NET 4, ed è praticamente stabile a questo punto. Lo usiamo già nel nostro prodotto commerciale. –

+0

Questo è il miglior consiglio che io abbia mai sentito per MEF utilizzato per cross platform a Mono. –

2
+0

Grazie. Dato che questo sarebbe un nuovo codice, non sono sicuro di utilizzare questo strumento (a meno che manchi qualcosa?). In altre parole, ho intenzione di usare CI per costruire entrambe le finestre in una versione Linux. –

+0

Ci sono alcune parti di Mono che non sono finite. Ad esempio mancano alcune cose in crittografia. Questi metodi/classi sono contrassegnati con attributi 'todo'. Moma ti indicherà quelle cose non implementate. –

2

Il progetto Mono fornisce un documento con portability guidelines. Questo è un buon punto di partenza.

+0

Se vale la pena notare che questo documento sembra un po 'obsoleto in alcuni punti. Ciò non significa che non sia pieno di informazioni utili. – Stewart

3

si dovrebbe essere interrested da Prebuild:

prebuild è uno strumento di pre-compilazione XML-driven multi-piattaforma che permette agli sviluppatori di generare facilmente file di progetto per gli strumenti di sviluppo .NET principali IDE e comprendente: Visual Studio. NET 2002, 2003, 2005, SharpDevelop, MonoDevelop, NAnt e Autotools.

+0

Perché il voto negativo? Il progetto Prebuid è molto utile per mantenere la stessa base di codice usando entrambe le piattaforme .NET e Mono. Ed è gratuito – Larry

0

Usiamo MonoDevelop e Visual Studio per lo sviluppo, ma ciò che è fondamentale è quello di mantenere attorno a una buona sceneggiatura NAnt costruire per costruire l'intera cosa in un solo colpo (regole di Joel Spolsky).

Il punto principale IMO è affermare molto chiaro che il software deve essere cross-piattaforma, quindi non si tratta di "porting per Linux/mono", ma in realtà sviluppare ogni iterazione sulle piattaforme richieste.

Abbiamo dovuto evitare alcune funzionalità all'inizio (utilizzando Mono/.NET per 5 anni per un prodotto commerciale) e continuiamo a utilizzare .NET Remoting, ma non è un grosso problema nello sviluppo multipiattaforma nel mio opinione.

Anche il conteggio del debugger da quasi un anno è una grande cosa.