8
votes

Comment puis-je déboguer dans une assemblée ilmérée?

Résumé strong>

Je souhaite modifier le processus de construction d'une solution à 2 assembly, de sorte qu'un appel à Ilmmerge soit invoqué et que la construction entraîne un seul assemblage. De plus, je voudrais pouvoir déboguer dans l'assemblée résultante. p>

Préparation - Un exemple simple strong> p>

  1. Nouvelle solution - Classlibrary1 Li>
  2. Créer une fonction statique 'getMessage' dans la classe1 qui retourne la chaîne "Hello World" Li>
  3. Créer une nouvelle application de console qui fait référence au classlibrary. Li>
  4. sortie GetMessage de Main () via la console. li> OL>

    Vous avez maintenant une application de montage à 2 sortire "Hello World" à la console. P>

    alors quoi ensuite. strong> P> P > J'aimerais modifier le processus de construction de l'application de la console, pour inclure une étape de publication qui utilise Ilmerge, pour fusionner l'assemblage de classeLibrary dans l'ensemble de la console P>

    après cette étape, je devrais pouvoir: P >

    • Exécutez l'application de la console directement sans classlibrary1.dll présent li>
    • Exécutez l'application de la console via F5 (ou F11) dans VS et être capable de déboguer dans chacun des 2 projets. LI> ul>

      Succès limité strong> p>

      J'ai lu Ce blogpost et a réussi à atteindre la fusion que j'étais après avec une commande post-build de ... p>

      CD %1
      Copy %2.exe temp.exe
      ILMerge.exe /out:%2.exe temp.exe ClassLibrary1.dll 
      Del temp.exe
      Del ClassLibrary1.*
      


3 commentaires

Plutôt que d'avoir un script .bat, une chose que vous pourriez faire est de créer un troisième projet (Type ClassLibrary fonctionnera) dont les dépendances sont ConsoleApp et ClassLibrary; Appelez cela postsuldolutionBuildVents. Ensuite, sa commande post-construction soit une commande iLMerge. De cette façon, vous avez accès à toutes les macros comme $ (solutiondir) .


Remarque: vous ne devez pas avoir besoin de des trucs de GAC à cette fin, il existe une énorme quantité d'options allant de «cela fonctionne simplement» lorsque rien n'est GACD aux fichiers de configuration de l'application


Avez-vous déjà résolu cela? Même problème ici...


4 Réponses :


1
votes

Je suggérerais que vous ne dégagez que des constructions de libération de vos assemblées. Je ne peux imaginer aucun avantage que vous obtiendriez de la fusion des assemblages de débogage.


5 commentaires

J'ai ajouté à ma question initiale expliquant (genre de) pourquoi je voudrais faire cela.


En ce qui concerne votre mise à jour, je pense que vous faites plus de problèmes que vous résolvez en essayant d'aller dans cette voie. Démarrez une nouvelle question en utilisant votre mise à jour comme question - il existe définitivement une meilleure solution que l'approche que vous essayez.


Je ne suis pas sûr de comprendre ... que suggérez-vous que je demande?


Décrivez ce que vous essayez de résoudre (plusieurs assemblages avec le même nom, mais différentes versions, dans le même répertoire) et demandez si quelqu'un a une meilleure solution que d'abuser ilmmerge.


L'avantage que je me réserve est de comprendre pourquoi il y a un problème d'enregistrement de Windsor Castle Windsor si je immine mais pas si je ne le fais pas.



-1
votes

Je ne pense pas que Ilmmerge puisse le faire. Otoh smartassemblybly à partir de la porte rouge (non libre) peut le faire, au moins donc il est dit à Caractéristiques

Et oui, je suis d'accord avec Mike d'utiliser uniquement Ilmmerge pour libérer versions.


0 commentaires

5
votes

Je suis désolé que vous ayez des problèmes. Je n'ai pas suivi vos étapes exactes, mais j'ai créé une application de console, A.exe, appelée méthode dans une DLL, B.DLL. J'ai construit les deux assemblages en mode de débogage (de sorte qu'ils disposaient de fichiers PDB). Je les ai ensuite fusionnés comme ceci:

ilmmerge /out:foo.exe a.exe b.dll

(réellement A et B étaient dans un autre répertoire, alors ma ligne de commande était un peu plus compliquée, mais cela ne devrait pas faire une différence.) Après que Ilmmerge terminé, il y a eu deux fichiers dans le répertoire actuel: FOO.EXE et FOO .pdb. J'ai ensuite tapé:

devenv foo.exe

Cela a ouvert un studio Visual et j'ai ensuite frappé "F10" pour démarrer le débogueur. J'ai pu entrer dans la méthode principale de l'exécutable puis utilisé "F11" pour entrer dans la méthode dans celle qui avait été à l'origine dans B.DLL. L'expérience de débogage n'était exactement la même que dans la solution originale Visual Studio avec les deux assemblages.

Si vous rencontrez toujours des problèmes, n'hésitez pas à mettre toute votre solution dans un fichier zip et à me l'envoyer (Mbarnet à Microsoft Dot com) et je peut l'essayer.


3 commentaires

+1 Pour une réponse de l'auteur d'Ilmmerge! Le fichier .PDB résultant fonctionne bien pour moi, s'il s'agit dans le même répertoire que l'assemblage fusionné (EXE dans mon cas). Voir des questions / réponses similaires Stackoverflow.com/questions/1439721/...


Cela a fonctionné parce que vous n'avez pas renommé de choses (voir ma réponse).


@MikeBarnett juste une note. Si l'EXE OUT a le même nom et le même emplacement (essentiellement, la sortie écrase l'EXE et PDB d'origine), l'application apparaît sur le démarrage au démarrage. Par exemple, ilmmerge /out:foo.exe foo.exe b.dll . La solution consiste à placer l'EXE et à assortir la PDB dans un répertoire différent iLmerge /out:foo.exe non licencié \ foo.exe b.dll . Fait intéressant, cela ne semble pas être un problème avec le commutateur / NDEBUG



0
votes

J'ai essayé de faire quelque chose comme ça et j'ai constaté que vous ne devriez pas renommer quoi que ce soit , ni avant pas après la fusion. Déplacer des trucs pour séparer le répertoire est bien. Si vous ne renommez rien, cela fonctionne.


0 commentaires