L'équivalent .NET des bibliothèques statiques?

Question

Je construis un outil en code managé (principalement C ++ / CLI) en deux versions, une version 'utilisateur normal' et une version 'pro'.

Le fait que le code de base est identique entre les deux versions m'a causé un peu de mal que je veux emballer l'outil résultant en un seul ensemble (DLL) et je ne veux pas avoir à inclure les fichiers .cpp pour le code commun dans les projets des deux versions des outils. Je préfère avoir un projet de code commun et un projet pour chaque version de l'outil et ont chaque version du projet d'outils dépendent du code commun et un lien dans comme vous le souhaitez.

En C ++ non managé je le fais en plaçant le code commun dans une bibliothèque statique et reliant les deux versions de l'outil à elle. Je ne semble pas être en mesure d'obtenir que cela fonctionne en C ++ / CLI. Il semble que je suis obligé de construire le code commun dans un ensemble de DLL et que les résultats dans plus de DLL que je voudrais.

Donc, en résumé, je ne peux pas travailler sur la façon de construire le code commun dans un projet et lien avec chacun des projets du produit final pour produire deux ensembles de DLL unique que les deux comprennent le code commun.

Je suis probablement faire quelque chose de mal, mais j'ai essayé de comment faire cela en utilisant netmodules et quel que soit et je ne pouvais pas le faire fonctionner. Finalement, la seule façon que je l'ai eu de travail était de dire l'éditeur de liens pour lier les produits de construction de l'ensemble de code commun plutôt que les résultats qui fonctionne, mais est un peu à mon humble avis hack.

De toute façon, quelqu'un at-il des suggestions sur la façon dont je devrais être résoudre ce problème?

Modifié: Je suppose que je aurais dû mentionner le fait que les assemblées générés ne sont pas 100% du code managé, ils contiennent un mélange de code managé et non géré comme il est, sans doute, assez fréquent avec des ensembles produits avec C ++ / CLI ...

Answer 1

Si vous êtes ennuyé à tous les DLL, téléchargez ILMerge . J'utilise ceci pour regrouper ensemble plusieurs DLL dans un .EXE facile à utiliser pour mes clients.

Answer 2

Comme le dit ILMerge est une façon, personnellement si votre Bundeling certains exe avec beaucoup de dll Je suis en faveur Netz .

Answer 3

Vous pouvez utiliser modules . Vous pouvez les relier dans un ensemble en utilisant l'éditeur de liens d'assemblage, al.exe.

Answer 4

Si je comprends correctement, vous avez une solution qui contient deux projets. Un projet pour l'utilisateur « normal » et un projet pour l'utilisateur « pro ». Visual Studio vous permet d'ajouter un « lien » à une autre source de fichier à partir d'un autre projet. Si votre version « pro » a le vrai fichier de code de base, et dans votre version « normale » vous ajoutez existant -> trouver le fichier dans le projet « pro » et cliquez sur la flèche bas par le bouton Ajouter et sélectionnez « Ajouter comme lien ». Maintenant, vous avez seul fichier qui est littéralement le même entre deux projets.

Answer 5

C'est l'inconvénient du processus de compilation .Net, vous ne pouvez pas avoir des choses comme les bibliothèques statiques et les fichiers d'en-tête qui détiennent les ensemble, tout se déroule dans un grand fichier dll et la seule façon de partager l'information est soit pour construire une dll commune et référence des autres assemblées ou à dupliquer le code dans chaque dll (éventuellement en copiant / liant les fichiers .cs entre les projets).

Notez que la 2ème façon déclarera différents types, même si elles ont le même nom. Cela vous mordre le cul avec des trucs comme remoting (ou tout ce qui nécessite la coulée d'interfaces partagées spécifiques entre les processus).

Answer 6

Remotesoft Salamandre va vous brancher. Il est essentiellement un compilateur natif et éditeur de liens.

Answer 7

Lors de l'utilisation mono (ou cygwin est une option) mkbundle peut également être un choix valide.