2010-03-02 4 views
2

Je ne sais pas pourquoi mais aujourd'hui myOpenID ne semble pas fonctionner. Quoi qu'il en soit ... J'ai ce problème: J'ai une bibliothèque C++ non gérée (DLL) que je dois intégrer dans un projet C# existant. Maintenant ... J'ai créé un mini-wrapper (DLL) en C++ géré qui appelle la bibliothèque pour que je puisse le charger à partir du code C# et, quand je l'essaie à partir d'un projet C# en ligne de commande, ça fonctionne parfaitement, résultats, bon comportement ecc.System.AccessViolationException lors de l'appel C++ à partir de C#

Maintenant, quand je le charge dans le projet réel, il commence à me donner une étrange exception System.AccessViolationException provenant de la DLL mini-wrapper. Je ne suis pas expérimenté en C#, ni en développement C++ managé/non managé sous Windows, et je ne comprends pas pourquoi cela devrait fonctionner à partir d'un projet C#, et non à partir d'un autre projet.

Plus d'informations: la bibliothèque d'origine utilise le moteur de rendu OGRE3D pour faire des calculs, et le projet dans lequel je dois utiliser cette bibliothèque utilise OGRE sous le capot, cela pourrait-il causer des problèmes?

Des suggestions?

+0

Est-ce que projet réel signifie une autre machine? Je veux dire, essayez-vous de vous utiliser dll dans des environnements différents? –

+0

Différents projets C# mais la même machine. – tunnuz

Répondre

1

Voici quelques idées pour vous d'essayer monsieur ...

  1. Il est difficile de savoir ce qui se passe exactement, mais la première chose que je voudrais essayer de faire est de supprimer ce géré C++ dll du mélange. Ce pourrait être des choses confuses. Quelque part ici, on a l'impression que les données ne sont pas correctement rassemblées entre le monde géré et non géré. De plus, le fait que le code ne fonctionne pas correctement à la console ne signifie pas que le code fonctionne correctement, mais il peut tout de même se casser, mais pas d'une manière qui déclenche une violation d'accès. La première chose que je regarderais utilise p/Invoke pour appeler votre dll non géré directement, si elle se casse, vous devez savoir assez rapidement:

    Calling Win32 DLLs in C# with P/Invoke

  2. Il se pourrait que quelque part dans le mix, ce pointeur est déplacé vers un espace adresse différent où ce pointeur n'a aucun sens. Y a-t-il des limites de processus ici?

Questions connexes