Best practice per una libreria .NET multi-target

Question

Sto pianificando di rilasciare una libreria .NET open source (MIT), ma anche di includere le DLL per rendere le cose facili per le persone in modo che non debbano compilare tutto da soli.

La mia libreria è molto semplicistica nei tipi a cui fa riferimento, l'unica vera dipendenza sembra essere .NET 3.0 o superiore (poiché si riferisce a Func<T> e simili).

Desidero che la mia libreria sia utilizzabile da più destinazioni, tra cui server .NET 4.0, server .NET 3.5, Windows Phone 7 Silverlight, Silverlight normale, XNA (telefono), XNA (Windows) e XNA (XBox 360) .

Mi assicuro di non utilizzare alcun tipo che non è disponibile sulle piattaforme che sto prendendo di mira, ad es. HashSet<T> non è disponibile su Windows Phone 7, quindi non lo sto utilizzando.

Avrò bisogno di fare diversi progetti e quindi più DLL per ognuno di questi obiettivi o c'è un modo per produrre una DLL comune per tutti loro da usare?

Answer 1

C'è stato un discorso al PDC quest'anno a fare questo genere di cose:

This is the video e these are the slides.

Answer 2

Suggerirei una libreria per ciascuna piattaforma. Lasciatemi spiegare.

Supponiamo che il completo .NET Framework includa un sacco di funzioni, metodi che non fanno parte dello .NET Compact Framework come quello che è possibile trovare con lo Windows CE e gli smartphone. Quindi, per sfruttare appieno il pieno carico di possibilità di ogni piattaforma, vorrei sfruttare una libreria comune con molte interfacce, quindi implementare tali interfacce all'interno di una libreria di classi .NET Framework platform specific che ti consentirà di sfruttare appieno ciò che viene offerto su una piattaforma specifica.

D'altra parte, se il riutilizzo comune del codice e per motivi di manutenibilità, si potrebbe preferire andare con una sola libreria "tutto-tutti-tutti". In base a tali requisiti, è necessario essere pienamente consapevoli di ciascuna delle differenze tra le numerose piattaforme che si desidera supportare.

Questa è ovviamente una questione di analisi e architettura importante, poiché entrambi soffriranno le carenze di una piattaforma rispetto all'altra.

Ecco come vorrei procedere di fronte a una situazione del genere:

1. vorrei indagare le differenze tra la piattaforma specifica .NET Framework;
2. Vorrei mettere da parte tutti (se necessario) gli oggetti comuni che pensate di aver bisogno;
3. Vorrei evidenziare le differenze, ovvero gli oggetti che è possibile utilizzare in una piattaforma, ma non nell'altra;

Questa è un'analisi organica che dovrai eseguire per vedere cosa succederà dopo.

Cioè, per una sorta di approccio a cascata.

---

Per quanto riguarda un approccio Scrum, se così si può dire come questo suggerisce l'empirismo, direi provare una singola libreria comune per tutti loro, e vedere cosa si può fare. Se ti imbatti in alcune cose che non puoi assolutamente fare, allora potrebbe essere rilevante solo creare un'altra libreria di classi che dipenderebbe dalla tua libreria "fai-da-tutti" in modo da avere un blocco comune per ogni piattaforma, quindi qualche altro specifico librerie per ciò che non puoi fare nel comune. Fallo, e vedi quali vantaggi hai ottenuto da esso, e trova un modo per uscire dai guai quando arriva il momento di essere più specifico.

Answer 3

Faccio qualcosa di simile con una libreria che si rivolge a .NET e Silverlight. Ho un singolo set di file sorgente e file di progetto separati che si collegano agli stessi file condivisi.

A volte uso la compilazione condizionale per includere funzionalità solo per .NET e non per Silverlight, o per sfruttare le funzionalità disponibili in .NET che portano a un'implementazione migliore e un'implementazione fallback per Silverlight in cui presenta lacune.

Lo stesso approccio potrebbe essere utilizzato per le altre piattaforme citate: un set di file sorgente, ma un file di progetto separato per piattaforma target.

Se si utilizza uno strumento di compilazione come MSBuild o NAnt, è possibile fare in modo che la build produca tutte le DLL per tutte le piattaforme di destinazione quando si esegue lo script.

Answer 4

Separare i file di progetto con file di origine comuni condivisi è la strada da percorrere. Assicurati che i progetti siano impostati per creare cartelle di output diverse (ad esempio non \bin\Debug, ma \CF\bin\debug) per evitare fastidi quando si utilizza la libreria da più destinazioni (come un progetto desktop e dispositivo).

Il OpenNETCF.IoC framework è un esempio di questo: supporta desktop, CF, Windows Phone e MonoTouch tutti con gli stessi file sorgente, ma file di progetto separati per piattaforma. Cercare di compilare un singolo assieme binario utilizzabile su tutti loro era troppo complicato e difficile da mantenere.

Il principale punto dolente qui è mantenere sincronizzati tutti i file di progetto quando si aggiungono/modificano file e si assicurano che tutti siano sempre compilati. Un server di build può farlo se si ha accesso all'automazione (che purtroppo Codeplex non espone).

Answer 5

sguardo al Portable Library Tools (Ultimo aggiornamento: 2011/06/17) estensione dalla BLC Team (Microsoft) e questa introduzione MSDN article (Ultimo aggiornamento: agosto 2011).