Je construis un outil dans le code géré (principalement C ++ / CLI) en deux versions, une version «utilisateur normale» et une version «Pro».
Le fait que le code de base est identique entre les deux versions m'a causé un peu de problèmes car je souhaite emballer l'outil résultant en tant qu'assemblage unique (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érerais avoir un projet pour le code commun et un projet pour chaque version de l'outil et que chaque version du projet Outils dépend du code commun et de le lier à volonté.
Dans le C ++ non géré, je le ferais en plaçant le code commun dans une bibliothèque statique et en reliant les deux versions de l'outil. Je ne semble pas être capable de faire fonctionner cela dans C ++ / CLI. Il semble que je sois obligé de construire le code commun dans un assemblage de la DLL et que cela entraîne plus de DLL que je voudrais.
Donc, en résumé, je ne sais pas comment construire le code commun dans un projet et lier à chacun des projets de produits finaux pour produire deux assemblages de DLL simples qui incluent tous les deux le code commun.
Je fais probablement quelque chose de mal mais j'ai essayé de déterminer comment faire cela en utilisant NetModules et tout ce que vous ne pouviez tout simplement pas le faire fonctionner. À la fin, la seule façon dont je l'ai fait fonctionner était de dire à la liaison de relier les produits de construction de l'Assemblée de code commun plutôt que des résultats qui fonctionne, mais est un peu de hack IMHO.
Quoi qu'il en soit, quelqu'un a-t-il des suggestions pour la manière dont je devrais résoudre ce problème?
édité: Je suppose que j'aurais dû mentionner le fait que les assemblages générés ne sont pas de code géré à 100%, ils contiennent une combinaison de code géré et non géré, comme c'est probablement assez courant avec les assemblages produits. avec C ++ / CLI ...
7 Réponses :
C'est l'inconvénération du processus de compilation .NET, vous ne pouvez pas avoir de choses comme des bibliothèques statiques et des fichiers d'en-tête qui les détiennent ensemble, tout est conservé dans un seul fichier DLL et le seul moyen de partager des informations consiste à construire une DLL commune et la référence à d'autres assemblées ou à dupliquer le code dans chaque DLL (éventuellement en copiant / reliant les fichiers .cs entre les projets).
Notez que la deuxième manière déclarera différents types, même s'ils ont le même nom. Cela vous mordra sur le cul avec des trucs comme des coupes (ou tout ce qui nécessite de jeter des interfaces partagées spécifiques entre les processus).
Pouvez-vous expliquer un peu plus sur votre deuxième paragraphe. Êtes-vous en train de dire que si j'ai le lien de liaison, la construction de produits de l'Assemblée du code commun dans l'assemblée finale, alors je vais avoir ces problèmes?
Oui, c'est pourquoi, lorsque vous vous remotez, les interfaces communes sont conservées dans un 3ème fichier .dll référencé par le serveur et les programmes clients. Avoir un type avec le même nom et la même structure dans 2 assemblages différents crée 2 types différents, contrairement aux bibliothèques C ++ non gérées qui ne contiennent aucune métadonnées et voient ainsi le même type structuré dans les deux versions du programme.
Si vous êtes ennuyé à tous les DLL, téléchargez Ilmmerge . J'utilise ceci pour regrouper plusieurs dll de plusieurs dlls facile à utiliser pour mes clients.
Je suppose que j'aurais probablement dû mentionner que l'une des assemblées n'est pas de 100% de code géré ... Ilmmerge ne fonctionne pas avec elle :(
Paul, j'ai accepté cette réponse car il s'agit de la meilleure réponse à des situations où il n'y a pas de code non géré dans les assemblées. Je cherche toujours une solution qui fonctionne avec des assemblées mixtes. Je n'ai pas encore enquêté sur la "chose des modules".
RemoteSoft Salamander vous accrochera. C'est fondamentalement un compilateur natif et un lieur.
Merci, a l'air un peu cher pour ce que je veux, mais je vais jeter un oeil tel qu'il peut également résoudre mes besoins d'obscurcissement ...
Le lien de réponse semble mort - "Ce site ne peut pas être atteint" .
@Pang Eh bien, ça fait 11 ans. Je pense que la société n'existe plus. Mais la fonctionnalité existe dans .NET CORE 3.X et UP.
Comme dit, ilmmerge est un moyen. Personnellement, si vous êtes en train de grouper des exe avec beaucoup de dlls, je préfère Netz .
1) On dirait que la sortie doit être une exe (mon application est emballée en tant que DLL). 2) Ne gère pas les ensembles de mixes gérées / non gérés C ++ / CLI.
1) Oui - il ne peut pas gérer "DLL-Seul" Emballage. 2) Avez-vous un coup d'œil sur "mkbundle" (voir autre réponse) - Cygwin peut être une condition préalable plutôt étrange mais imo mkbundle gère des mélanges gérés / non gérées - Mais: Je n'ai pas encore été essayé. (toujours voulu, difficile)
Je n'ai pas essayé mkbundle, mais je vais maintenant au point où je peux l'essayer (c'est-à-dire avoir le temps et l'inclination pour obtenir toutes les conditions préalables installées et travailleuses) prendront un certain temps.
Développement arrêté il y a quelques années
Lorsque vous utilisez Mono (ou Cygwin est une option) Mkbundle peut aussi être un choix valide.
Vous pouvez utiliser modules . Vous pouvez les relier à un assembly à l'aide de la liaison de montage, al.exe .
J'ai essayé cela et je ne pouvais pas le faire travailler, connaissez-vous un exemple non trivial de la manière de la configurer? Idéalement, le code peut être construit avec VS2008 et les modules fusionnés avec une étape de construction personnalisée?
Non, je ne sais pas. Les modules sont jolis ésotériques.
Si je comprends cela correctement, vous avez une solution contenant 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 fichiers d'un autre projet. Si votre version "Pro" a le fichier de code de base réel, et dans votre version "normale", vous ajoutez existant -> Recherchez le fichier dans le projet "PRO", puis cliquez sur la flèche vers le bas par le bouton Ajouter et sélectionner "Ajouter en tant que lien ". Maintenant, vous avez un fichier unique qui est littéralement la même entre deux projets.
Erik, qui pourrait fonctionner, bien que ce soit un peu de douleur d'un point de vue de l'évolutivité (c'est-à-dire pas facile d'ajouter un autre projet qui dépend de 90% du code dans le projet 1). Je vais lui donner un coup.
Vrai, mais j'imagine que le problème de l'évolutivité ne sera que dans une question entre différentes versions normales, pro, etques. Si vous allez écrire du code contre votre propre dll, j'imagine que vous allez utiliser la version Pro :).
Je recommande fortement de vous débarrasser de l'idée que vous devez l'emballer dans une seule DLL.