[C#] Class Library personalizzata

[mcaisco]

Vorrei creare una mia class library (dll) in C# per poi poterla utilizzare in altri progetti .net.
Tanto per provare ho iniziato con una cosa idiota, ma già così non riesco a far funzionare la dll.
Spiego...

Ho creato una nuova soluzione con visual studio in C#, scegliendo "Class Library". Quindi nella soluzione ho un progetto che ho chiamato "MyLibrary" con dentro un'unica classe pubblica "MathLibrary" in cui ho definito un metodo idiota che fa la somma di due interi. Ecco insomma la mia libreria di prova:

File: MathLibrary.cs
using System;

namespace MyLibrary
{
public class MathLibrary {

public int somma(int a, int b) {
return a + b;
}
}
}

Stupidissima... vabbè. Compilo tutto e in effetti in bin/debug (ma anche in bin/release) c'è la mia MyLibrary.dll.

Poi ho creato un altro progetto, sempre nella stessa soluzione di visual studio. Ho creato un semplice progetto console, nominato Client. Dentro ho creato (beh lo fa automaticamente visual studio) una classe Program.cs che dichiara il metodo "static void main()".
A questo punto aggiungo al progetto Client una reference alla dll ottenuta con l'altro progetto (MyLibrary). Come ho fatto? Beh visual studio permette di scegliere librerie esterne presenti anche in altri progetti (c'è proprio una tab apposita). E infatti vedevo chiaramente la mia MyLibrary.dll.
Una volta aggiunta la reference alla mia libreria completo il Program.cs nel progetto Client inserendo un paio di righe dentro al main() per usare la mia libreria. Ecco qui come:

File: Program.cs
using System;

namespace Client
{
class Program
{
static void Main(string[] args) {
MyLibrary.MathLibrary math = new MyLibrary.MathLibrary();
// scrivo nella console di visual studio
System.Diagnostics.Trace.WriteLine(math.somma(1, 1));
}
}
}

A questo punto setto come progetto di esecuzione (Set as StartUp Project) il progetto Client in modo che lanci il main dentro la classe Program. Lancio e tutto funziona bene, nella console stampa un bel 2!

Però mi accorgo che insieme all'eseguibile Client.exe mi produce anche un copia locale della mia libreria. Beh questo può essere concepibile ma io vorrei che la cosa funzionasse anche con la dll posizionata in altro luogo e senza creare una copia locale. Per fortuna c'è una proprietà fra quelle delle reference (tasto destro, proprietà, sulla reference alla mia MyLibrary.dll) che si chiama "copy local" e mi accorgo che è settata a TRUE. Beh la metto a FALSE, ricompilo, eseguo Program.cs e... BOOOOOM. Mi dice che non riesce a trovare l'assembly MyLibrary!!!

Eppure sempre fra le proprietà della reference alla mia libreria c'è il Path usato che è corretto (C:\Documents and Settings\Utente1\Desktop\MyLibrary\MyLibrary\MyLibrary\bin\Release\MyLibrary.dll). Fra le righe stampate sulla console di Visual Studio in fase di compilazione riporta chiaramente la compilazione e il linking delle librerie usate, e le librerie usate, essendo librerie del framework, sono tutte dll esterne con copy local = FALSE come per la mia dll. Ma non la mia non sembra riuscire a trovarla...

Help!

[gugoXX]

Una delle cose belle del .net e' che non sporca troppo in giro, usando concetti come registri o come directory predifinite.
Per fare cio', tutto cio' che serve per un progetto e che non e' qualcosa di sistema (come le librerie del framwork), viene copiato integralmente nella directory eseguibile.
Intal modo, quando si dovra' disinstallare il programma, sara' sufficiente rimuovere la directory.

Quindi una soluzione possibile e consigliata e' quella di lasciare CopyLocal a true, e portarsi dietro la DLL tutto laddove serve.

Alternativa possibile e' quella di far uso della GAC, che e' il luogo ove vengono mantenute le librerie installate sulla macchina alla stregua di quelle di sistema.

Dovrai quindi firmare l'assembly che contiene la libreria (SN)
installare l'assembly nella GAC (GacUtil)
Meglio se cerchi in giro qualche documento perche' non e' proprio intuitivo.

a questo punto quando la includerai in uno dei tuoi progetti successivi, la troverai ovviamente tra gli assembly .NET, e non lo dovrai quindi scegliere navigando le directory.

[mcaisco]

Mmm infatti sto googlando un po' e le cose cominciano a quadrare.

Dunque vediamo se riesco a capire. Unendo quello che mi hai detto con quanto letto fino ad ora sul web sembra che le librerie .net (assemblies) utilizzate da un progetto .net possano essere eseguite localmente o in maniera condivisa.

Localmente significa che l'eseguibile di un progetto effettuerà il linking dinamico alla libreria che si trova all'interno della propria directory di esecuzione, e questo avviene appunto quando una reference ad un assembly viene impostata con Copy Local = True.

Condivisa significa invece che l'eseguibile del progetto .net andrà a ricercare la libreria da linkare in un repository univoco per tutta la macchina locale. Questo repository dovrebbe essere sta benedetta GAC (Global Assembly Cache). Tutte le librerire registrate nella GAC sono utilizzabili in maniera condivisa da qualunque progetto/eseguibile .net, senza che la dll debba essere copiata in locale. Insomma un'unica dll per tutti.

Personalmente sto facendo delle prove proprio per capire il funzionamento di .net su questo lato. Però alla fine dei conti io vorrei creare una specie di framework fatto di varie dll, riutilizzabili da vari progetti .net che potrei dover creare nel tempo. Gli eseguibili dovranno poi essere installati su macchine diverse, quindi vorrei evitare di dover ogni volta copiare tutte le dll del framework per ogni eseguibile che produco. Mi sembra logico invece che il framework con le sue dll venga installato (nella GAC locale di ogni macchina a questo punto) una volta per tutte e poi vengano distribuiti solo i nuovi eseguibili.
Sbaglio?

[gugoXX]

Questo e' vero fintantoche' la libreria rimane stabile e non modificata.
Altrimenti dovrai gestire anche la distribuzione della libreria, gli aggiornamenti etc.
Dovrai anche risolvere i problemi delle versioni installate sulle varie macchine, e cosa maggiore l'eventuale retrocompatibilita' (cosa che dovresti comunque fare in locale pero' in qualsiasi caso, mantenendo il codice delle varie versioni di libreria che hai poi usato almeno una volta in uno dei tuoi programmi).

Quando la libreria puo' cambiare, ti consiglierei di usare l'approccio "CopyLocal".
Non e' sicuramente la manciata di KB di una libereria copiata piu' che appesantisce un hard disk. Cosi' facendo problemi di DLL-Hell non ne avresti, in quanto la singola DLL sarebbe sicuramente aggiornata al momento del delivery del singolo eseguibile, nella sua directory.
Nella soluzione di eventuali aggiornamenti online, difficlmente dovrai aggiornare solo un file. Dovrai molto probabilmente aggrionare vari file di configurazione, risorse, etc. la DLL sarebbe semplicmente un file in piu'...

Poiche' la maggior parte delle volte la libreria vive, evolve tanto quanto se non di piu' degli eseguibili che la usano, l'approccio "copy local" lo preferisco.

[mcaisco]

Capisco. Beh in effetti potrebbe essere problematico avere un'unica versione condivisa delle librerie.
Però dalle prove che sto facendo non è nemmeno possibile inserire tutte le librerie all'interno di una directory sotto la directory in cui eseguo l'eseguibile. CIoè sembra che le librerie in locale debbano stare tutte brutalmente nella stessa directory dell'eseguibile... e che cavolo! Il linker non si spreca nemmeno a cercare nelle sottodirectory quindi?!?!