L'equivalente .NET delle librerie statiche?

Sto costruendo uno strumento in codice gestito (principalmente C++/CLI) in due versioni, una versione "utente normale" e una versione "pro".L'equivalente .NET delle librerie statiche?

Il fatto che il codice principale sia identico tra le due versioni mi ha causato un piccolo problema poiché voglio impacchettare lo strumento risultante come un singolo assembly (DLL) e non voglio dover includere il .cpp file 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 ogni versione del progetto degli strumenti dipende dal codice comune e collegarlo come desiderato.

In C++ non gestito farei questo posizionando il codice comune in una libreria statica e collegando ad esso entrambe le versioni dello strumento. Non riesco a farlo funzionare in C++/CLI. Sembra che sono costretto a costruire il codice comune in un assembly DLL e che risulta in più DLL di quanto vorrei.

Quindi, in sintesi, non riesco a capire come creare il codice comune in un progetto e collegarlo a ciascuno dei progetti del prodotto finale per produrre due singoli assembly DLL che includono entrambi il codice comune.

Probabilmente sto facendo qualcosa di sbagliato, ma ho cercato di capire come farlo usando i netmodules e qualsiasi altra cosa e non riuscivo a farlo funzionare. Alla fine l'unico modo in cui l'ho fatto funzionare è stato dire al linker di collegare i prodotti di costruzione dell'assembly di codice comune piuttosto che i risultati che funzionano ma è un po 'un hack IMHO.

In ogni caso, qualcuno ha qualche suggerimento su come DOVREBBE risolvere questo problema?

Modificato: credo avrei 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 ...

fonte

2009-10-02 Len Holgate

Consiglio vivamente di eliminare l'idea che è necessario comprimerlo in una singola DLL. –

Se si è infastiditi da tutte le DLL, scaricare ILMerge. Lo uso per raggruppare più DLL in un .EXE facile da usare per i miei clienti.

fonte

2009-10-02 08:55:18 PaulMcG

Grazie, darò un'occhiata. –

Probabilmente avrei dovuto dire che uno degli assiemi non è un codice gestito al 100% ... ILMerge non funziona con questo :( –

Paul, ho accettato questa risposta in quanto è la migliore risposta per le situazioni in cui c'è nessun codice non gestito negli assembly Sto ancora cercando una soluzione che funzioni con assembly misti Non ho ancora studiato la "cosa dei moduli" –

Questo è lo svantaggio del processo di compilazione .Net, non è possibile avere cose come librerie statiche e file di intestazione che li tengono insieme, tutto è contenuto in un unico file dll e l'unico modo per condividere informazioni è quello di creare una dll comune e fare riferimento ad altri assembly o duplicare il codice in ogni dll (possibilmente copiando/collegando file .cs tra i progetti).

Si noti che il 2o modo dichiarerà diversi tipi, anche se hanno lo stesso nome. Questo ti morderà il culo con cose come il remoting (o qualsiasi cosa che richieda il casting su specifiche interfacce condivise tra i processi).

fonte

2009-10-02 08:49:53 Blindy

Puoi spiegare un po 'di più sul tuo secondo paragrafo. Stai dicendo che se avrò il linker link i prodotti di costruzione del codice comune nell'assemblaggio finale avrò questi problemi? –

Sì, ecco perché quando si esegue il servizio remoto, le interfacce comuni sono conservate in un file .dll di terze parti a cui fanno riferimento sia il server che i programmi client. Avere un tipo con lo stesso nome e struttura in 2 diversi gruppi crea complessivamente 2 tipi diversi, a differenza delle librerie C++ non gestite che non contengono metadati e quindi vedono lo stesso tipo strutturato in entrambe le versioni del programma. – Blindy

Remotesoft Salamander ti collegherà. È fondamentalmente un compilatore e un linker nativo.

fonte

2009-10-02 08:58:55 AngryHacker

Grazie, sembra un po 'costoso per quello che voglio ma prenderò un guarda come può anche risolvere i miei requisiti di offuscamento ... –

Ancora non gestisce gli assembly misti gestiti/non gestiti ... –

Come detto ILmerge è unidirezionale, personalmente se il tuo bundeling qualche exe con un sacco di dll I favore Netz.

fonte

2009-10-02 09:00:29 Nils

Grazie Nils, ci proverò! –

1) Sembra che abbia bisogno dell'output per essere un exe (la mia domanda è confezionata come una DLL). 2) Non gestisce gli assembly C++/CLI gestiti/non gestiti misti. –

1) sì - non può gestire l'imballaggio "solo dll". 2) Hai dato un'occhiata a "mkbundle" (vedi altra risposta) - cygwin può essere un prerequisito piuttosto strano ma IMO mkbundle gestisce gestito/miscele non gestite - MA: non l'ho provata acually. (sempre voluto, difficile) – Nils

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

fonte

2009-10-02 09:04:38 Nils

È possibile utilizzare modules. È possibile collegarli a un assieme utilizzando il linker dell'assieme, al.exe.

fonte

2009-10-02 09:10:39

Ho provato e non ho potuto farlo funzionare, conosci un esempio non banale di come impostare questo? Idealmente in modo che il codice possa essere creato con VS2008 e che i moduli vengano uniti con una fase di creazione personalizzata? –

No, non lo so. I moduli sono piuttosto esoterici. –

Se sto capendo correttamente, hai una soluzione che contiene due progetti. Un progetto per l'utente "normale" e un progetto per l'utente "pro".Visual Studio ti consente di aggiungere un "link" a un'altra sorgente di file da un altro progetto. Se la tua versione "pro" ha il vero file di codice di base, e nella tua versione "normale" aggiungi esistente -> trova il file nel progetto "pro" e fai clic sulla freccia in giù con il pulsante Aggiungi e seleziona "Aggiungi come collegamento ". Ora hai un singolo file che è letteralmente lo stesso tra due progetti.

fonte

2009-11-12 04:17:38

Erik, Potrebbe funzionare, anche se è un po 'un problema dal punto di vista della scalabilità (non è facile aggiungere un altro progetto che dipende dal 90% del codice nel progetto 1). Ci provo. –

Vero, ma immagino che il problema della scalabilità si verificherà solo in un problema tra diverse versioni normale, pro, ecc. Se stai per scrivere un codice contro la tua DLL, immagino che userete la versione pro :). –

L'equivalente .NET delle librerie statiche?

risposta

Problemi correlati