Il .NET equivalente di librerie statiche?

Question

Sto costruendo uno strumento in codice gestito (per lo più C ++ / CLI) in due versioni, una versione 'normale utente' e una versione 'pro'.

Il fatto che il codice di base è identico tra le due versioni mi ha causato un po 'di problemi come voglio confezionare lo strumento risultante come un unico gruppo (DLL) e io non voglio avere a includere i file cpp per il codice comune nei progetti delle due versioni degli strumenti. Preferirei avere un progetto per il codice comune e un progetto per ogni versione dello strumento e avere ogni versione del progetto strumenti dipendono dal codice comune e collegarlo in, se lo desideri.

In unmanaged C ++ farei questo mettendo il codice comune in una libreria statica e collega entrambe le versioni dello strumento ad esso. Non mi sembra di essere in grado di ottenere questo a lavorare in C ++ / CLI. Sembra che io sono costretto a costruire il codice comune in un assembly DLL e che si traduce in più DLL di quanto mi piacerebbe.

Così, in sintesi, non riesco a capire come costruire il codice comune in un unico progetto e collegarlo con ciascuno dei progetti del prodotto finale per la produzione di due assemblee DLL singoli che sia includere il codice comune.

Probabilmente sto facendo qualcosa di sbagliato, ma ho cercato di capire come farlo usando netmodules e qualsiasi altra cosa e io non riuscivo a farlo funzionare. Alla fine l'unico modo che ho capito di lavoro è stato quello di dire al linker per collegare i prodotti di generazione del gruppo di codice comune, piuttosto che i risultati che funziona, ma è un po 'di un IMHO hack.

In ogni caso, qualcuno ha qualche suggerimento per come dovrei essere per risolvere questo problema?

Modificato: Credo che dovrei avere accennato al fatto che le assemblee generati non sono al 100% di codice gestito, che contengono un misto di codice gestito e non gestito come è, probabilmente, abbastanza comune con i gruppi di prodotti con C ++ / CLI ...

Answer 1

Se si è seccato per tutte le DLL, scaricare ILMerge . Io lo uso per raggruppare insieme più DLL in un EXE di facile utilizzo per i miei clienti.

Answer 2

Come ha detto ILMerge è un modo, personalmente se la vostra bundeling qualche exe con un sacco di DLL Io sono a favore Netz .

Answer 3

Si potrebbe utilizzare moduli . Si possono collegare in un assieme utilizzando il linker assemblaggio, al.exe.

Answer 4

Se ho la comprensione di questo correttamente, si dispone di una soluzione che contiene due progetti. Un progetto per l'utente "normale" e un progetto per l'utente "pro". Visual Studio consente di aggiungere un "link" ad un'altra fonte di file da un altro progetto. Se la versione "pro" ha il file di codice vero nucleo, e nella versione "normale" si aggiunge esistente -> trovare il file nel progetto "pro", e fare clic sulla freccia verso il basso dal pulsante Aggiungi e selezionare "Aggiungi come link ". Ora avete un singolo file che è letteralmente lo stesso tra due progetti.

Answer 5

Questo è il lato negativo del processo di compilazione Net, non si può avere le cose come librerie statiche ei file di intestazione che li tengono insieme, tutto si svolge in un unico grande file dll e l'unico modo per condividere le informazioni è quello di costruire uno una dll comune e riferimento da altri gruppi o di duplicare il codice in ogni dll (possibilmente copiando / collegamento di file cs tra i progetti).

Si noti che il secondo modo in cui dichiarerà tipi diversi, anche se hanno lo stesso nome. Questo ti morderà sul culo con roba come i servizi remoti (o qualsiasi cosa che richiede la fusione per interfacce condivise tra i processi specifici).

Answer 6

Remotesoft Salamander vi collegare in su. E 'fondamentalmente un compilatore nativo e linker.

Answer 7

Quando utilizza mono (o cygwin è un'opzione) mkbundle anche può essere una scelta valida.