Discussion :

[vikz]

bonjour tlm,

J'ai développé une application en C# utilisant une dll que j'ai fait en C++/CLI (qui elle-même fait appel à des lib en C++).

En générant ma solution sous Visual 2005, ca marche sans problème.

Mais en copiant mon appli + la dll sur un autre poste (possédant Framework 2.0), je reçois le message : "Le programme a cessé de fonctionner".

Pour déterminer mon problème, j'ai crée un projet c# bidon vide faisant appel ou non à ma dll. Conclusion : avec la dll ca marche pas, et sans ma dll, ca marche.

Donc j'ai un problème avec la dll. Mais, en créant une dll contenant une classe bidon qui ne fait rien, même pb :/

dll :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
namespace DllTest {
 
	public ref class ClassTest
	{
	public:
		void Test()
		{
		};
	};
}

appli :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
namespace AppliTest
{
    public partial class FormTest : Form
    {
        private DllTest.ClassTest m_test = new DllTest.ClassTest();
 
        public FormTest()
        {
            InitializeComponent();
        }
    }
}

La dll est bien ajoutée dans les références de mon appli.

Pourriez-vous m'indiquer une piste svp ?

[cinemania]

essaie de lancer ton appli en ligne de commande

l'avantage c'est qu'elle cessera de fonctionner, mais si une exception non catchée est levée à l'intérieur, elle sera récupérée sur la console.

[smyley]

Tient juste en passant, l'ordi sur lequel tu développes a la même architecture de processeur de celui sur lequel tu test ? (32bits, 64bits)

[vikz]

merci de vos réponses,

alors j'ai développé sur Vista 32bit, et j'ai spécifié x86 comme plate-forme cible

j'ai testé en ligne de commande mais même résultat.

Par contre ds le rapport d'erreur, j'ai :
EventType : clr20r3 P1 : applitest.exe P2 : 1.0.0.0 P3 : 47d001eb
P4 : applitest P5 : 1.0.0.0 P6 : 47d001eb P7 : 5 P8 : e
P9 : system.io.fileloadexception

fileloadexception : je vois pas trop pourquoi

[smyley]

Mais en copiant mon appli + la dll sur un autre poste (possédant Framework 2.0), je reçois le message : "Le programme a cessé de fonctionner".

oui mais tu as testé sur Vista 32 ou Vista 64 ?

Sinon dans la méthode Main de ton Program.cs englobe le tout par un try-catch pour afficher l'erreur.

[vikz]

je fais des tests sur Vista 32 et XP SP2

l'exception catchée est la suivante :

Impossible de charger le fichier ou l'assemby
'DllTest, Version=1.0.2988.24524, Culture=neutral,
PublicKeyToken=null' ou une de ses dépendances.Impossible
d'accorder les demandes d'autorisation minimales. (Exception de
HRESULT : 0x80131417

[SaumonAgile]

ça veut dire que les autorisations de sécurité que ton assembly demande ne sont pas accordées à l'utilisateur qui lance l'application. Tu essaies d'exécuter ton programme avec un compte invité ? une machine avec des droits limités ?

[vikz]

merci pour ta réactivité

j'ai déjà envisagé cette possibilité et donc j'ai fait mes tests sur un compte administrateur pour éviter ce genre de pb.

[smyley]

Ton application tu l'exécute bien à partir d'un emplacement local (disque C: et tout et tout) et pas à partir d'un emplacement distant, sur un réseau ?

[vikz]

oui bien-sur

[cinemania]

ta dll a telle changé de version en cours de route ?
si oui, il faut recompilé la dll certes, mais surtout le programme appelant...
surtout si la dll a été signée numériquement, ou enregistré dans le GAC.
dans le cas du GAC il faudra envisager d'enregistrer la nouvelle à la place de l'ancienne

[vikz]

On m'a parlé également de GAC. Je vais me renseigner sur ce que c'est.

Mais je pensais qu'en ajoutant le projet créant la dll dans les références (Visual C++ 2005), que l'application et les dll générées auraient des signatures compatibles

[cinemania]

tout dépend si tu change la version d'une dll en cours de route ou non.
même si le fichier change mais la version et toujours la meme, tu peux changer la dll comme tu le souhaite, en revanche dès que tu change le buildcode de la dll, son nom pleinement qualifié change également, ce qui remet completement en cause le lien entre ton application et la dll.

N'oublie pas que quand tu fait Ajouter Référence, tu fait une liaison de type 'statique' et forte, autogérée par le système, il sera donc regardant à la moindre virgule...
si tu utilise la liaison tardive (charger l'assembly dynamiquement) là les choses sont différentes, tu peux ignorer totalement le nom pleinement qualifié et la signature de la dll, en contrepartie... les types fourni par la dll ne sont pas connus à la compilation, et tu dois te tapper de la Reflexion à tout va.

Quand je parle du changement de version j'entend dans le répertoire où sont stocké les binaires. Si la version de la dll change, il faut impérativement recompiler le projet qui en dépend avec la nouvelle version.

[vikz]

merci, je vais essayer une liaison tardive pour voir.