Problème d'execution d'applications Winforms (c++)

Bonjour,

J'ai un problème avec visual C++ 2005 Express edition.
Quand je fais une application Winforms, je peux l'executer sans problème sur mon PC (depuis Visual, ou depuis n'importe quel répertoire de mon PC).

Mais si je place mon .exe sur un disque en réseau et que je le lance depuis mon PC, ou si je copie mon .exe sur un autre PC et que je l'execute sur cette autre PC, j'ai ce message d'erreur dans une boîte de dialogue "Débogage juste-à-temps":

"Une exception 'System.IO.FileLoadException' s'est produite dans DefaultDomain'.

Ca ne peut pas venir de mon code, car ça le fait aussi sur une application toute simple. Exemple: Je crée un projet Winforms tout simple avec Visual qui affiche une fenêtre vide et je ne modifie pas le code:
http://texelinside.free.fr/bugs/Test_WinForms.zip

Je sais plus quoi faire :(

C'est un problème de sécurité je crois. Par défaut, la configuration du Framework ne te permet pas d'exécuter un programme .NET sur une machine distante.

Ok. Merci.

Mais pourquoi mes programmes ne fonctionnent pas sur d'autre PC (depuis leur propre disque dûr) et quand ceux-ci ont le runtime d'installé ?

toujours un probleme de sécurité et de droits d'accès aux "fichiers"

'System.IO.FileLoadException'

le fait que le client soit installé sur le poste directement ne t'absout pas de remplir les règles de sécurités nécessaire, et de respecter les droits inalienables d'accès aux fichiers.

Attention lorsque tu fait une copie chez le client à vérifier les privilèges utilisateurs sur l'accès au fichier. Un des fichiers dont ton appli dépend est soit absent (pas copié ou pas accessible car chemin introuvable), soit pas accessible pour des raisons de droits d'accès.

Mon programme de dépend d'aucun fichier. J'ai créé un projet vide (celui qui affiche une fenêtre Winforms vide généré par Visual) et j'ai compilé => Même problème. (Je n'ai par contre aucun problème avec mes programmes qui n'utilisent pas les winforms, mais seulement l'api win32 et DirectX).

C'est bizzar, aujourd'hui, le message d'erreur est différent sur les autres PC:

Citation:

---

Cette application n'a pas pu démarrer car la configuration de l'application est incorrecte.

---

Avec ce nouveau message, j'ai trouvé sur google qu'il fallait installer ce programme sur le poste client:
http://www.microsoft.com/downloads/d...9-220B62A191EE

Une fois installé, ça marche sur les postes clients, mais uniquement si le programme est compilé en mode release.

Pour info: Sans ce "redistribuable Visual 2005", mon programme ne fonctionne pas sur deux PC ayant aussi installé Visual 2005 et .NET SDK 2.0 (et donc même version que moi).

Est ce qu'il existe un moyen de se passé de ce runtime pour le poste client ?
Dans les config de Visual 2005 peut-être ?
Est ce que c'est encore un problème de sécurité ?

Citation:

---

le fait que le client soit installé sur le poste directement ne t'absout pas de remplir les règles de sécurités nécessaire, et de respecter les droits inalienables d'accès aux fichiers.

---

Qu'est ce que tu veux dire par là ? tu veux dire: simplement vérifier que les fichiers (images, ...) qu'utilise mon application sont bien là où cherche mon programme, ou est ce que ça concerne la façon de configurer son projet et de compiler l'application ?

non je pensais aux droits d'accès aux fichiers.

windows 2000 et ultérieurs sont sur une base NT. pour peu que tu utilise une partition NTFS, il y a des droits d'accès aux fichiers (ACL) et si tu n'a pas les droits requis, ton programme ne peut pas fonctionner.

Je ne connais pas beaucoup de chose au développement sous Windows.
Je ne comprend pas.

Est ce que je dois gérer des droit d'acces au DLL de l'API de fenêtrage de mon application et aux DLL du runtime .NET ?
Je trouve ça vraiement bizar et incomprehenssible. Ce sont des runtimes.

non les assembly du framework sont dans des répertoires avec des droits pour le "Tout le monde" en lecture et exécution (ou tout au moins pour le groupe utilisateurs/utilisateurs authentifiés si tu bosse dans un domaine et que le domain admin est un parano fini)