Ciao Marco,
la stessa dll non potrà funzionare sia su .NET 2.0 che su Linux pertanto sarà necessario che lo stesso codice venga compilato per target framework diversi.

Per nuovi progetti potresti crearti una libreria rivolta al .NETStandard 1.4 per avere la garanzia che funzioni sul maggior numero di piattaforme: PC Windows con .NET Framework 4.6.1, dispositivi con il supporto alla Universal Windows Platform (questo include Windows Phone e le Raspberry pi 2 e 3) e applicazioni multipiattaforma scritte per il .NET Core 1.0 (quindi Windows, Linux o Mac OS X).

Leggi qui come creare tale libreria.
https://docs.nuget.org/ndocs/guides/create-net-standard-packages-vs2015#create-the-class-library-project

Per le vecchie versioni del framework dovrai effettuare compilazioni separate ed ottenere altre dll. Ecco uno spunto:
http://www.cyotek.com/blog/targeting-multiple-versions-of-the-net-framework-from-the-same-project

Alla fine, quando hai ottenuto varie .dll, puoi incapsularle in un pacchetto NuGet per facilitare il download agli sviluppatori che la useranno (può essere un feed NuGet privato aziendale).

Ecco l'esempio di un pacchetto molto popolare come JSON.NET. Nella sua pagina puoi vedere come sia appunto rivolto a varie versioni del framework.
https://www.nuget.org/packages/Newtonsoft.Json/
Come ripeto: il pacchetto non contiene una sola dll "universale" ma molteplici versioni. Se vai a vedere il sorgente del progetto hai anche un secondo spunto:
https://github.com/JamesNK/Newtonsoft.Json/blob/master/Build/build.ps1
In questo caso è stato usato uno script powershell per invocare msbuild con vari parametri per effettuare tutte le compilazioni necessarie ad ottenere le dll.

Comunque, dovresti essere più specifico su ciò che intendi realizzare. Ad esempio, hai effettivamente delle applicazioni scritte per il Framework 2.0 su cui devi utilizzare questa libreria? La libreria cosa fa esattamente? E' per tuo uso interno o intendi distribuirla/venderla?

ciao,
Moreno

---

Modificato da BrightSoul il 02 gennaio 2017 20.34 -

Ciao Marco,

Allora dovrei distribuire questa DLL a dei nostri clienti, per farla integrare nei loro applicativi.

Ok, allora creati assolutamente un repository NuGet aziendale e distribuiscila come pacchetto. Non solo è un modello di distribuzione più professionale e ben documentato, ma ti eviterà di sprecare ore in assistenza per rispondere ai clienti che vogliono una certa versione X per il framework Y, sulla piattaforma Z.
Con NuGet, tutte le versioni restano sempre visibili e immodificabili, così eviti anche le lamentele del tipo "...ma la versione che mi avevi inviato per email 6 mesi fa funzionava, mentre quella che mi hai inviato oggi non funziona più".

Detto questo, resta valido l'approccio che ti dicevo nel post precedente. Prendi ad esempio il codice di Newtonsoft.Json e creati delle soluzioni diverse per ogni target framework. Poi crea degli script PowerShell per avviare la compilazione. Trovi i file da cui prendere spunto nella cartella build del repository GitHub.
https://github.com/JamesNK/Newtonsoft.Json/tree/master/Build

Questa DLL ha la funzione di scrivere su un database e/o file

Opzionalmente, se pensi che sia il caso, puoi spezzare il progetto in più sotto-progetti. Cioè: se un tuo cliente vuole scrivere su file, non gli dare anche il codice per scrivere nel database.
Puoi crearti un pacchetto NuGet "essenziale" che conterrà il grosso della logica della libreria. Per la persistenza, invece, crea un pacchetto per ogni meccanismo che intendi supportare e che conterrà solo la logica di salvataggio. Ti troverai quindi con dei pacchetti chiamati così:

NomeLibreria (contiene la logica essenziale e indipendente dal meccanismo di persistenza)
NomeLibreria.SqlServer (dipende dal pacchetto NomeLibreria e serve a persistere su db)
NomeLibreria.FileDiTesto (dipende dal pacchetto NomeLibreria e serve a persistere su file di testo)

Gli sviluppatori dei tuoi clienti potranno così scegliere liberamente solo i pacchetti che intendono effettivamente utilizzare. E' lo stesso principio usato da molti altri pacchetti popolari, come quelli prodotti da Microsoft stessa (vedi esempio).

ciao,
Moreno

---

Modificato da BrightSoul il 04 gennaio 2017 14.01 -