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

Je suis en train de construire un outil en code managé (la plupart du temps C++/CLI) en deux versions, une "normale" l'utilisateur "et une version" pro " de la version.

Le fait que le code de base est identique entre les deux versions m'a causé un peu de mal car j'ai envie de package de l'outil comme une assemblée unique (DLL), et je ne veux pas avoir à inclure l' .fichiers cpp pour le code commun dans les projets des deux versions de l'outil. Je préfère avoir un projet pour le code commun et un projet pour chaque version de l'outil et ont chaque version du projet d'outils dépendent de la commune de code, et de le lier en tant désiré.

Dans le C++ je le ferais en plaçant le code commun dans une bibliothèque statique, et reliant les deux versions de l'outil. 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 une DLL à l'assemblée et que les résultats en plus de la DLL que je le 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 produit final des projets pour produire deux DLL unique assemblées que les deux comprennent le code commun.

Je suis probablement fait quelque chose de mal mais j'ai essayé de travailler sur la façon de le faire à l'aide de netmodules et que ce soit et je ne pouvais pas le faire fonctionner. En fin de compte la seule façon que j'ai eu de travail était de dire à l'éditeur de liens pour lier les produits de construction de la commune de code de l'assemblée plutôt que sur les résultats qui fonctionne mais est un peu un hack à mon humble avis.

De toute façon, quelqu'un aurait-il des suggestions pour la façon dont je DEVRAIS être la résolution de ce problème?

Édité: je suppose que je devrais avez mentionné 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 managé comme c'est, sans doute, assez commun avec les assemblées produites avec C++/CLI...

Je vous recommandons fortement de se débarrasser de l'idée que vous avez besoin pour emballer le tout dans un seul fichier DLL.

OriginalL'auteur Len Holgate | 2009-10-02

  1. 6

    Si vous êtes gêné à toutes les Dll, téléchargement ILMerge. Je l'utilise pour relier plusieurs DLL en un facile à utiliser .EXE pour mes clients.

    Merci, je vais jeter un oeil.
    Je suppose que je devrais probablement avoir mentionné que l'une des assemblées n'est pas 100% de code managé... ILMerge ne fonctionne pas avec elle 🙁
    Paul, j'ai accepté cette réponse car c'est la meilleure réponse pour les situations où il n'y a pas de code non managé dans les assemblées. Je suis toujours à la recherche d'une solution qui fonctionne avec un mélange d'assemblages. Je n'ai pas étudié les modules de chose encore.

    OriginalL'auteur PaulMcG

  2. 2

    Comme l'a dit ILmerge est une façon, personnellement, si votre bundeling certains exe avec beaucoup de dll je préfère Netz.

    Merci Nils, je vais l'essayer!
    1) Semble avoir besoin de la sortie vers un fichier exe (mon application est emballé comme une dll). 2) Ne gère pas mixte géré/C++/CLI assemblées.
    1) oui - il ne peut pas gérer les "dll " seulement" emballage.. 2) Avez-vous eu un coup d'oeil sur "mkbundle" (voir autre réponse) - cygwin peut-être un peu étrange condition préalable, mais l'OMI mkbundle ne poignée de sites gérés et non gérés mixes MAIS: je havn't en fait essayé. (toujours voulu, dur)
    Je n'ai pas essayé mkbundle mais maintenant arrivé à un point où je peux l'essayer (c'est à dire le temps et l'envie de toutes les conditions préalables installé et en fonctionnement) va prendre un certain temps.
    Développement arrêté il ya quelques années

    OriginalL'auteur Nils

  3. 1

    Vous pouvez utiliser les modules de. Vous pouvez faire un lien dans un assemblage à l'aide de l'assemblée de l'éditeur de liens, al.exe.

    J'ai essayé et je ne pouvais pas le faire fonctionner, connaissez-vous un petit exemple non trivial de savoir comment configurer? Idéalement de manière à ce que le code peut être construit avec VS2008 et les modules fusionné avec une étape de génération personnalisée?
    Non, je ne sais pas. Les Modules sont assez ésotérique.

    OriginalL'auteur Anton Tykhyy

  4. 1

    Si je comprends bien, vous avez une solution qui contient deux projets. Un projet pour l'utilisateur "normal" et un projet pour les "pro" de l'utilisateur. Visual Studio vous permet d'ajouter un "lien" vers un autre fichier source à partir d'un autre projet. Si votre version "pro" est le véritable coeur de fichier de code, et dans votre "normal" de la version que vous ajoutez existant -> trouver le fichier dans le "pro" du projet, et cliquez sur la flèche vers le bas par le bouton Ajouter et sélectionnez "Ajouter un Lien". Maintenant, vous avez seul fichier qui est littéralement le même entre les deux projets.

    Erik, Qui pourraient travailler, mais c'est un peu d'une douleur, d'une évolutivité point de vue (c'est à dire pas facile à ajouter un autre projet qui dépend à 90% du code dans le projet 1). Je vais lui donner un aller.
    Vrai, mais j'imagine que le problème d'évolutivité va seulement être dans un problème entre les différents normal, pro, etc versions. Si vous allez écrire du code à l'encontre de votre propre DLL, j'imagine que vous allez utiliser la version pro :).

    OriginalL'auteur Erik Philips

  5. 0

    C'est l'inconvénient de l' .Net processus de compilation, vous ne pouvez pas avoir des choses comme les bibliothèques statiques et les fichiers d'en-tête que de les faire tenir ensemble, tout se tient dans un seul gros fichier dll et le seul moyen de partager des informations, soit de construire une commune dll de référence et des autres assemblées ou de dupliquer le code dans chaque dll (éventuellement en les copiant ou en les reliant .cs des fichiers entre les projets).

    Noter que la 2ème façon de déclarer les différents types, même si elles ont le même nom. Cela va vous mordre sur le cul avec des trucs comme remoting (ou quelque chose qui nécessite un casting pour partagé spécifique des interfaces entre les processus).

    Pouvez-vous expliquer un peu plus à propos de votre deuxième paragraphe. Dites-vous que si j'ai le lien de l'éditeur de liens, le code commune de l'assemblée produits de construction dans l'assemblage final, puis je vais avoir ces problèmes?
    Oui, c'est pourquoi, lorsque l'on remoting, les interfaces communes sont tenues dans un 3ème .dll fichier référencé par le serveur et le client de programmes. Ayant un type avec le même nom et la structure en 2 différentes assemblées crée 2 types différents au total, à la différence de C++ bibliothèques qui ne contiennent pas de méta-données et ainsi de voir le même type structuré dans les deux versions du programme.

    OriginalL'auteur Blindy

  6. 0

    Remotesoft De La Salamandre vous accrochera. En gros, c'est un natif du compilateur et de l'éditeur de liens.

    Merci, ressemble un peu cher pour ce que je veux, mais je vais prendre un coup d'oeil comme il peut également résoudre mon dissimulation des exigences...
    Encore ne gère pas mixte réussi/non géré assemblées...

    OriginalL'auteur AngryHacker

  7. 0

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

    OriginalL'auteur Nils