Module d'update : FileLoadException

Version imprimable

17/07/2009, 09h58
Flyyd

Module d'update : FileLoadException

Bonjour,

Je me trouve devant le problème suivant : les updates.

Pour diverses raisons je ne peux pas utiliser ClickOnce...

Mon soft est segmenté en une dizaine de DLL et bien sur j'aimerai pouvoir les changer directement dans l'exe via sa partie réseau.

Je récupère alors un fichier zip contenant mes dll est j'arrive à les extraire dans le répertoire contenant les vieilles versions à changer et mon exe. Là j'essaye deux méthodes :
1) je crée un update manager : problème je peux pas updater l'updateur...
2) je trouve une information sur google : je peux modifier le nom de mes dll (en rajoutant .tmp au bout par exemple) puis extraire mes dll du zip, il suffira alors d'attendre que le programme se relance.

Mon problème est alors le suivant : toutes ces opération se passe bien mais dans la première méthode comme dans l'autre j'ai l'erreur suivante dès que mon programme commence à utiliser mes dll : FileLoadException was unhandled. "La définition trouvée du manifeste de l'assembly ne correspond pas à la référence de l'assembly. (Exception de HRESULT : 0x80131040)"

J'ai bien sûr effectuer des recherches sur internet mais sans comprendre les résultats retournés :s

La question est donc simple : comment puis je remplacer mes dll ?

D'avance merci :)

Flyyd

Salut.

Utilise tu la reflexion et les liens tardif? on dirait que non...

Je te file un bout de code qui provient d'un de mes programmes. Je m'en sert pour dynamiquement charger mes plugins, avec ca, rien ne m'enpeche durant l'execution de charger, decharger mes dlls. J'espere que ca sera parlant.

Interface de mes plugin. Chaque classe exposée par ma DLL doit implementer cet interface , et cette interface est dans une dll qui est statiquement chagée (un projet, et dans mon soft j'ajoute une reference à ce projet). Cet interface ne doit jamais changer biensur, sinon il faudra recompiler toutes les classes qui l'implémente :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public interface IPluginTemplate : IDisposable
    {
        ResourceManager Resources
        {
            get;
        }
 
        bool IsSet
        {
            get;
        }
 
        String Name
        {
            get;
        }
 
        String ToString();
 
 
        Form SettingsForm
        {
            get;
        }
 
}

Code dans ce qui pourrait etre ton updater (et qui ne change jamais d'une version à l'autre, en fait meme lui et mon interface IPluginTemplate sont dans la meme dll que je ne touche jamais.) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
 public static class PluginManager
    {
        #region plugins fnc
 
        public static IPluginTemplate LoadPluginFromFile(String path)
        {
            String _found = String.Empty;
            object obj = null;
 
 
            if (Path.GetFileName(path) != "GODKI_PluginTemplate.dll")
            {
                _found = GetPluginClassFromDll(path);
                if (_found != String.Empty)
                {
                    obj = AppDomain.CurrentDomain.CreateInstanceFromAndUnwrap(path, _found);
 
                }
            }
            if (obj is IPluginTemplate)
                return (IPluginTemplate)obj;
            else return null;
        }
 
        public static IPluginTemplate[] SearchPlugins()
        {
            IPluginTemplate[] _result;
            object obj = null;
 
            List<IPluginTemplate> _list = new List<IPluginTemplate>();
 
 
            String _path = String.Format("{0}", Environment.CurrentDirectory);
            String[] _dlls = Directory.GetFiles(_path, "*.dll");
 
 
            foreach (String item in _dlls)
            {
                obj = LoadPluginFromFile(item);
                if (obj != null)
                    _list.Add((IPluginTemplate)obj);
            }
            _result = new IPluginTemplate[_list.Count];
            _list.CopyTo(_result);
            return _result;
 
        }
 
        public static String GetPluginClassFromDll(String path)
        {
            Assembly _assembly = Assembly.LoadFrom(path);
            Type[] _types = _assembly.GetExportedTypes();
            //TODO : rajouter une exception si on trouve plus d'un type
            foreach (Type item in _types)
            {
                if (item.IsClass && !item.IsAbstract && item.GetInterface("GODkeyImporter.IPluginTemplate") != null)
                    return (item.ToString());
            }
            return String.Empty;
        }
        #endregion
    }

note enfin que rien ne nous empecherai à la ligne
[CODE]return (IPluginTemplate)obj;[CODE]

de faire une verif du genre obj.Version >= actual version

Voila j'espere que ca t'aidera :)

17/07/2009, 10h31
Flyyd

Merci de ta rapidité !

Une question que je comprenne bien tout ça !

Je code mes dll dans la même solution (sous visual studio) et j'utilise pour les implémenter l'ajout par référence via mes différents projets. "Add a référence" et les différentes DLL qui sont représenté dans l'onglet "Mes projets".

Si je lis entre les lignes de ta réponses il s'agit d'un chargement statique et c'est là que se situe mon problème ?

Faut il que je supprime ces dll de mes référence ? Dans le cas où j'implémente ta solution comment puis je faire pour utiliser après mes dll dans mes autres dll ?

Flyyd
17/07/2009, 10h45
Flyyd

Je suis entrain d elire ce tutorial : http://emerica.developpez.com/dotnet...uction/csharp/

Je le poste là pour information si vous êtes dans le même cas que moi !

Flyyd
17/07/2009, 11h10
giova_fr

tout à fait, ton probleme viens de là.
Retire les references vers tes dll (qui font que c'est un chargement static au lancement du programme)
puis adapte le bout de code que je t'ai donné pour faire un chargement dynamique.

Soit bien concient que ceci impose un inconvénient:
Vu que tu va faire un chargement dynamique, tu ne pourra plus bénéficier de l'intellisence sur tes classes pendant que tu code.

Ca n'est qu'au moment de l'execution que tes dll sont chargées, donc le compilateur n'a pas connaissance de leur contenu pendant la phase de développement.
17/07/2009, 11h16
Flyyd

Merci !

J'indique le sujet comme résolu :)

Citation:

Envoyé par giova_fr

tout à fait, ton probleme viens de là.
Retire les references vers tes dll (qui font que c'est un chargement static au lancement du programme)
puis adapte le bout de code que je t'ai donné pour faire un chargement dynamique.

Soit bien concient que ceci impose un inconvénient:
Vu que tu va faire un chargement dynamique, tu ne pourra plus bénéficier de l'intellisence sur tes classes pendant que tu code.

Ca n'est qu'au moment de l'execution que tes dll sont chargées, donc le compilateur n'a pas connaissance de leur contenu pendant la phase de développement.

Bonjour,

Dans ton code je n'arrives pas a savoir si la fonction suivante devrais renvoyer le string d'une interface ou le string d'une classe normale.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 public static String GetPluginClassFromDll(String path) { Assembly _assembly = Assembly.LoadFrom(path); Type[] _types = _assembly.GetExportedTypes(); foreach (Type item in _types) { if (item.IsClass && !item.IsAbstract && item.GetInterface("GODkeyImporter.IPluginTemplate") != null) return (item.ToString()); } return String.Empty; }
je n'entre jamais dans la condition

Code:

if (item.IsClass && !item.IsAbstract && item.GetInterface("MadllInterface.Iinterface") != null)

quand j'essaie de l'adapter en partant de la supposition qu'on essaie de trouver les interfaces, donc en fait j'aimerai bien savoir a quoi correspond "GODkeyImporter.IPluginTemplate".

Cordialement.

25/07/2009, 18h11
giova_fr

Salut, la string retourné représente le type de la Classe trouvé, le if le dit d'ailleur,
Pour chaque type trouvé dans l'assembly
si le type représente une classe non abstraite et qui implement l'interface machin
on retourne ce type sous la forme d'une string.

Pour que ta condition soit vrai, il faut que le parametre path désigne le chemin complet d'une dll contenant au moins une classe non abstraite qui implémente l'interface "MadllInterface.Iinterface"

Pour reprendre la chose dans son ensemble, tu dois donc avoir 3 choses :

1) une dll définissant une interface (MadllInterface), l'objectif etant de ne jamais modifier cette dll.

2) l'application qui charge statiquement ta dll d'interface (via une reference donc)

3) une ou plusieurs dll (plugin) qui charge statiquement ta dll d'interface (via une reference donc), et qui définissent une ou plusieurs classes implémentant l'interface.

3 choses sont alors à conclure :
a) l'application dépend de la dll interface
b) les dll plugins dépendent egalement de la dll interface
c) l'appli ne dépend pas des dll plugins

C'est pour cette raison que l'interface ne doit jamais changer, sinon il faut modifier l'appli et toutes les dll plugin à chaque modif. L'avantage en revanche c'est que tu peux ajouter de nouvelle dll plugin, sans toucher à ton appli.

Une fois que les ellements 1) 2) & 3) existent, tu peux alors dans l'appli implémenté mon jeu de fonctions pour dynamiquement charger tes dll plugin.

Pour en finir, le role de la dll Interface : c'est une facade pour toutes tes dll plugin , elle permet de dire à l'appli, quelles methodes on va appeller dans tes classes chargées dynamiquement.