Exécution de mstest * sans * it à l'aide d'un ThreadPool

Question

J'écris du code managé pour envelopper les appels natifs pour IntervalZero's RTX product. RTX permet essentiellement le codage en temps réel sous Windows en configurant un proxy du noyau. Ce qui est important ici, c'est que RTX génère le proxy quand DllMain est appelé avec DLL_THREAD_ATTACH (et l'arrête sur DLL_THREAD_DETACH). Si ce proxy n'a pas été généré et que vous passez un appel dans la bibliothèque, vous obtenez un immédiatement BSOD. Eh bien, je suis sûr à 99,9% que lorsque mstest.exe exécute ses tests unitaires, il les met en file d'attente en utilisant la classe ThreadPool (c'est la seule chose qui explique ce comportement). La chose malheureuse est que le thread a déjà été créé avant que la bibliothèque RTX soit chargée, donc DllMain n'est jamais appelé et le sous-système RTX ignore son existence, et quand un test unitaire essaie d'appeler dans la bibliothèque, les choses se défont . Je dois vraiment pouvoir faire des tests unitaires sur ce genre de choses afin d'obtenir une couverture de test raisonnable et automatisable. est-il possible de dire à mstest de générer un nouveau thread lors de l'exécution de chaque test? Je sais que ce serait normalement plus lent, mais ça va être beaucoup plus rapide que de revenir après un écran bleu.

Answer 1

Eh bien, puisque mon taux d'acceptation est faible en raison de questions comme celle-ci, je vais fournir une réponse (mais pas celle que j'aime). Je ne pense pas qu'il soit possible de se comporter de façon différente (c'est-à-dire en utilisant un seul thread par test). J'ai essayé à peu près tout ce qui était imaginable. La solution pour cela consistait à écrire une application de test simple qui utilisait la réflexion pour charger et exécuter les tests. En faisant cela, j'ai gardé la syntaxe la plus monstrueuse (mais avec beaucoup moins de fonctionnalités). À long terme, ce qui doit arriver, c'est que les API RTX nécessitent un massage plus convivial. Je travaille avec l'OEM pour essayer de l'obtenir dans la prochaine version.

Answer 2

Avez-vous essayé d'utiliser un framework différent de MSTest comme nUnit pour voir si cela reproduit le problème?