AppDomains multiples: maintenir la console ouverte

Question

J'ai un faisceau de test d'intégration qui lance une console exe plusieurs fois, simultanément, chacun dans son propre domaine d'application. Dès que l'une des applications exe de la console quitte son domaine d'application, stdin, stdout, stderr se ferme pour tous les autres domaines d'application exe de la console. C'est-à-dire que la console est fermée même si l'application continue. C'est dommage, car les autres "applications de console" encore actives ont du matériel supplémentaire à afficher sur l'écran. Je voudrais savoir s'il existe un moyen de maintenir la console ouverte, même si l'une des sorties de la console fonctionne, jusqu'à ce que je sois prêt et que la console soit vraiment arrêtée. Pour les curieux, mon harnais de test d'intégration s'exécute à partir du framework de test unitaire VS (vstesthost.exe). Je ne pense pas que ce détail soit pertinent à la question, mais j'aimerais que la console reste ouverte jusqu'à ce que mon test soit terminé. Certes, le framework de tests unitaires ne doit pas s'appuyer sur la sortie de la console pour sa valeur, mais cela aide quand je débogue les tests. BTW, le fait que je cours un test d'intégration à partir d'un cadre de test unitaire est hors sujet. :)

Answer 1

Approche intéressante ... Je me demande, même si vous corrigez cela, comment vous avez l'intention de traiter les problèmes de concurrence sur std.out et std.err?

Je l'ai déjà fait plusieurs fois pour résoudre la question:

1. créer le domaine de l'application
2. créer un objet MarshalByRef dans le nouveau domaine
3. passer un TextWriter personnalisé dans la nouvelle domaine
4. remplacer les valeurs de std.err et std.out dans .NET via Console.Set ???? (TextWriter)
5. exécuter une ou plusieurs ensembles dans le domaine

J'espère que vous aurez l'idée, votre écrivain de texte personnalisé peut ensuite synchroniser la sortie au besoin. Je ne sais pas si le domaine de l'application enfant hériterait de la console personnalisée du domaine parent.Out/Error ou non, vous pouvez également essayer de simplifier le code requis.