Pourquoi le code natif appelé à partir de .net donne-t-il un résultat différent de l'appel d'un programme natif?

Question

Nous avons une bibliothèque native que nous utilisons pour effectuer des tâches liées à la sécurité pour nous. Nous avons écrit une bibliothèque d'interopérabilité afin que nous puissions l'utiliser à partir de .NET.

Nous avons deux applications de test, la première application est écrite en C++ (non gérée) et la seconde est écrite en C#. Ils génèrent exactement la même séquence d'appels à la bibliothèque native, mais produisent des résultats différents.

Je suis perdu et ne trouve aucune erreur apparente dans les définitions d'importation .NET. Je l'ai déjà bousillé pour que je ne travaille qu'avec une interface très simple. Je suis à la recherche d'idées pour lesquelles l'appel d'une bibliothèque native à partir d'un environnement .NET peut influencer le résultat.

EDIT: Je n'ai pas une connaissance approfondie de la bibliothèque, donc je ne peux pas fournir beaucoup de choses sur ce qui est fait dans le code natif. Je sais qu'il maintient un fil (heatbeat). Une autre partie de la bibliothèque, utilisée pour identifier si l'application s'exécute sur une machine virtuelle, présente également le même comportement. Ce n'est pas nécessairement lié.

J'ai écrit une autre application de test en C++/CLI, car il est un peu plus facile de consommer la bibliothèque native qu'à partir du C# et elle donne aussi le même résultat que le C#.

Answer 1

Wild devinez: vous marshal une fonction prenant bool à une fonction prenant bool. Cela donne des résultats différents lors de l'appel à partir du code natif et du code managé car bool ne doit pas être converti en bool

Answer 2

Une possibilité serait que la bibliothèque native utilise le stockage local de thread natif. Il n'y a pas (nécessairement) de correspondance entre les threads gérés et les threads natifs. Pour éliminer cette possibilité, vous pouvez essayer d'encapsuler toute la séquence d'appels dans les appels à BeginThreadAffinity/EndThreadAffinity (c'est-à-dire, une seule paire de ces appels pour tous les appels dans la bibliothèque, pas une paire autour de chaque appel individuel dans la bibliothèque)

Answer 3

mots clés:

nous avons écrit une bibliothèque Interop afin que nous puissions l'utiliser (bibliothèque native) de .NET.

Ceci est la source de vos erreurs et non la bibliothèque native. Un appel natif spécifique (appel de fonction spécifique w/paramètres spécifiques) retournera les mêmes résultats, peu importe comment il est appelé. Le problème est que votre wrapper peut introduire des bugs subtils où vous "pensez" que vous faites le même appel mais la version interop fait un appel légèrement différent (donc des résultats différents).

Je commencerais par quelques tests unitaires très fins de votre librairie interop au plus bas niveau. Fonction native foo (int x, int y). Appelez-le nativement, appelez-le via la bibliothèque. Le résultat devrait être le même. Continuez jusqu'à ce que vous trouviez un appel de fonction là où il ne l'est pas. S'il y a une différence entre le problème et votre numérotation &, n'interopez pas la bibliothèque native. Si vous trouvez un appel individuel qui renvoie des résultats de différence et que vous ne pouvez pas trouver la source de l'erreur dans interop, alors postez un appel individuel comme une question sur SO.

Answer 4

Il pourrait y avoir un problème avec le marshalling/interop comme d'autres l'ont suggéré.

Mais il se peut aussi que la bibliothèque native fasse des hypothèses sur son environnement qui ne sont pas exprimées uniquement dans les signatures d'appel.

Il existe de nombreuses façons de faire de telles hypothèses. En tant qu'exemple aléatoire, une méthode dans une bibliothèque MFC qui n'appelle pas la macro AFX_MANAGE_STATE peut faire des hypothèses non valides lors de l'appel à partir du code .NET.