2010-07-16 4 views
1

Un peu en arrière, j'ai posé une question ici sur la façon d'exécuter une application en tant que fil dans l'espace mémoire d'une autre application, plutôt un nouveau processus: Executing a program as a thread and not as a processExécution d'une application en tant que fil et non un processus

En guise de suivi à cette question, je pense que j'ai une théorie sur la façon dont je pourrais le faire pour réaliser ce que j'essaie de faire. Tout d'abord, permettez-moi de dire que la raison pour laquelle je fais cela est parce que j'essaie de créer une application de test qui puisse «tester» d'autres applications, mais les contrôler si elles obtiennent une exception. et le restructurer automatiquement. Ma théorie sur la façon de le faire est de créer une interface, appelée par exemple ITestBed et de mettre en œuvre la classe principale dans mon application. L'implémentation contiendra une méthode, TestApp(), par exemple. Tout ce que j'ai besoin de faire à partir de mon application de banc d'essai est d'appeler cette méthode et cette méthode du côté de l'application peut simplement refléter le constructeur de mon objet actuel? Est-ce que ça va marcher? Essentiellement, ce que j'essaie de faire est de mimmick comment fonctionne Visual Studio. Si vous définissez un point d'arrêt dans votre programme, appuyez sur pour exécuter votre application dans Visual Studio, votre application s'exécute en tant qu'enfant de l'application Visual Studio. Pour tester cela, vous pouvez mettre fin à l'application de studio visuel et votre application prendra également fin. Comment puis-je réaliser ceci?

+0

duplication possible de [Exécution d'un programme en tant que thread et non en tant que processus] (http://stackoverflow.com/questions/3169234/executing-a-program-as-a-thread-and-not-as- a-process) –

+0

Vous inventez une roue. Au moins jeter un oeil sur le code source pour NUnit: http://launchpad.net/nunitv2/2.5/2.5.5/+download/NUnit-2.5.5.10112-src.zip –

+0

@HansPassant Avec tout le respect, Monsieur: Incase vous n'avez pas remarqué, les roues gardent le monde en mouvement (avions, voitures, vélos, planches à roulettes ...): P. – SE13013

Répondre

2

Vous n'avez pas besoin de l'exécuter en tant que thread séparé.

Lorsque vous utilisez Process.Start pour lancer un processus, il s'agit d'un processus fils de l'application en cours.

Surveillez simplement l'événement Process.Exited (en vous assurant de définir EnableRaisingEvents sur true) et utilisez-le pour voir quand le processus se termine. Vous pouvez ensuite redémarrer le processus automatiquement à ce moment-là.


Ma théorie sur la façon de le faire est de créer une interface, appelée ITestBed par exemple, et avoir la classe principale dans mon application mettre en œuvre. L'implémentation contiendra une méthode, TestApp(), par exemple. Tout ce que j'ai besoin de faire à partir de mon application de banc d'essai est d'appeler cette méthode et cette méthode du côté de l'application peut simplement refléter le constructeur de mon objet actuel? Est-ce que ça va marcher?

Cela fonctionnera. Vous pouvez charger l'assemblage de l'exe principal par réflexion et construire l'objet principal, puis appeler votre méthode. Cela fait cependant partie du processus de votre application actuelle, ce qui entraîne des effets secondaires. Vous partagez l'espace mémoire du processus dans cette situation.

Si vous faites cela, vous voudrez peut-être regarder dans les domaines d'application. En chargeant et en "lançant" votre implémentation ITestBed dans un AppDomain distinct, vous protégez votre application principale.

+1

Pour suivre la réponse de Reed: il est assez facile d'écrire une application qui gâchera tout le processus dans lequel il se trouve (même si vous l'isolez dans un AppDomain). Le * processus * est le champ de travail approprié pour ce genre de choses. Visual Studio utilise des processus enfants - pas de threads - pour le débogage. –

Questions connexes