J'écris un test d'unité C# pour tester la fonctionnalité C++/CLI qui implique des threads.Le test d'unité .net se bloque avec "Impossible de passer un GCHandle sur AppDomains" lorsqu'il est appelé depuis un thread étranger
Le code C++/CLI implémente un filtre DirectShow, l'API Windows pour le rendu des films. Cela fonctionne ainsi que je crée des objets DirectShow, je lui dis d'exécuter un AVI par le biais de mes filtres C++/CLI, attend que le rendu soit terminé, puis quitte. Mon filtre a un rappel qui donne les images vidéo à C# pour le traitement. DirectShow fonctionne ainsi qu'il crée son propre thread et appelle mes objets COM à partir de ce thread.
Maintenant, ce truc fonctionne quand je cours mon code normalement, mais quand j'exécute un test unitaire à partir de Resharper, il échoue avec l'erreur "Impossible de passer un GCHandle sur AppDomains". Ce qui semble mal fonctionner, c'est que Resharper utilise AppDomains dans son testeur, et que le thread DirectShow n'est pas associé à ce domaine. Comment puis-je faire ce test à partir de Resharper?
Existe-t-il un paramètre NUnit/Resharper pour contrôler si des domaines d'application sont utilisés? Puis-je dire au CLR que le thread est associé à un domaine particulier? Connaissez-vous d'autres solutions de contournement pragmatiques?
TIA Jan
Merci pour ce lien. J'avais beaucoup de mal à faire fonctionner mon système d'événements où un thread natif distinct appelait le monde géré. J'ai construit un mécanisme simple en utilisant une classe contenant 'gcroot' pour empêcher la collecte de mes délégués + pointeurs de fonction créés par 'Marshal.GetFunctionPointerForDelegate()' pointant vers mes délégués. Dans mes déclencheurs d'événements, j'appelle simplement le pointeur de fonction et la transition AppDomain est effectuée automatiquement. –
Danielku15