J'ai besoin de compiler du code à l'aide de codedomProvider.compileAssemblyfromsource . Comment voudrait-il le déboguer? Fondamentalement, je veux le compiler, créer une instance d'un type, puis entrer dans le code du type.
3 Réponses :
Avez-vous essayé d'attacher au processus à l'aide de votre code à partir du débogage> Joindre à la fonction de processus dans VS?
question intéressante. Je pense que votre meilleur pari serait d'utiliser Windbg pour joindre à la course à pied .NET EXE Process (Je pense que vous devrez le faire après que le Tyoe ait été compilé en mémoire, car les adresses de mémoire de l'EXE vont changer - je suppose).
Ensuite, lorsque le type est compilé et exécuté en mémoire, vous pouvez ensuite rechercher ce type à l'aide de commandes trouvées dans sos.dll. Vous pouvez également placer des points d'arrêt en mémoire en utilisant SOS.DLL
Mise en route avec SOS Link
http: // rionisimpsoni .wordpress.com / 2009/10/08 / Obtenir-commencement-windbg-and-sos-dll /
Ceci est un peu de réponse léger, car expliquant comment utiliser WINDBG et SOS.DLL a été couvert à plusieurs reprises sur le Web.
EDIT:
L'un des inconvénients de cette méthode est que vous ne pourrez pas voir le code source comme Visual Studio l'affiche. Vous verrez la langue d'assemblage affichée lorsque vous traversez le code. Cela pourrait vous mettre déjà désactivé :), mais si vous vous en tenez avec cela et comprends un peu d'assemblage, vous pourriez faire suffisamment pour déboguer les erreurs par exemple.
Une autre chose que vous pourriez faire est de jeter l'assemblage .NET de la mémoire dans un fichier sur disque. La commande sos.dll à faire qui m'échappe maintenant, je vais y chercher ...
ahh, c'est Savemodule . Un exemple de ceci peut être trouvé dans les commentaires ici .
Après avoir posté une question, j'ai réalisé que mon problème était que je produisais l'assemblée à partir de la chaîne, pas du dossier. Je suis retourné et j'ai changé le code pour fonctionner avec différentes options lors de la débogage et je suis capable de passer à partir du code de test unitaire. En outre, il faut définir la générationInmemory sur False et inclusebinformation à vrai.
#if DEBUG
@params.IncludeDebugInformation = compilationContext.IncludeDebugInformation;
@params.GenerateInMemory = compilationContext.GenerateInMemory;
var fileName = Path.GetFullPath(Path.Combine(AppDomain.CurrentDomain.BaseDirectory,@"..\..\" + compilationContext.AssemblyOutputName + ".cs"));
File.WriteAllText(fileName,compilationContext.StringToCompile);
return _codeDomProvider.CompileAssemblyFromFile(@params,fileName);
#else
return _codeDomProvider.CompileAssemblyFromSource(@params, compilationContext.StringToCompile);
#endif
Observation intéressante, l'assemblage généré comme celui-ci ne doit pas se terminer par la DLL d'être utilisable, il n'est pas nécessaire de disposer d'une extension du tout.
+1 Belle question et réponse de soi et très apropos pour moi. Je suis en plein milieu de la génération et de la compilation de code de test à la volée. C'est utile.
@Wilkins: Merci, content que cela ait aidé quelqu'un d'autre. Mon truc est même un peu plus impliqué, je génère du code qui génère le code qui est ensuite compilé et exécuté. Donc, être capable de déboguer était un must pour moi ici.
Qu'entendez-vous par «avec option en mémoire»? Avez-vous essayé simplement d'attacher le débogueur au processus de course?
Bien que cela ne soit pas ce que vous voulez, qu'en est-il de simplement générer l'assemblage sur le disque et le charger comme s'il s'agit d'un assemblage existant, juste à des fins de débogage? Je comprends la nécessité de générer l'assemblée au moment de l'exécution, mais il n'y a rien de mal à choisir certaines conditions d'exécution et à les reproduire au moment de la compilation :)