Eviter les DLL externes

Bonjour

Pour les besoins d'une petite procédure d'installation je crée un lien dans Windows.

Pour créer des liens, il faut une référence COM sur 'Windows Script Host' comme ça après on peut faire :

Code:

---

1 2 3 4

WSH.WshShell shell = new WSH.WshShell(); WSH.IWshShortcut link = (WSH.IWshShortcut)shell.CreateShortcut("lien.lnk"); link.TargetPath = "executable.exe"; link.Save();

---

Évidemment pour fonctionner une DLL d'interopérabilité est créée : 'Interop.IWshRuntimeLibrary.dll'.

Seulement voila maintenant pour fonctionner, mon programme d'installation à besoin d'une DLL externe. Je perds donc tout l'intérêt de l'installation s'il faut soi-même installer manuellement une DLL !!!

Et la solution de ZIPPER mon programme avec ses DLL ne me convient pas. Car c'est vraiment alourdir une procédure d'installation pour une personne ayant des connaissances limités en info.

Et puis il doit bien avoir une méthode pour intégrer directement une DLL à l'exécutable !? Non !?

Cependant cette méthode ne me saut pas aux yeux ni sur Google ! 8O

Bonjour.

Regarde du coté de Cecil afin d'intégrer le code de la lib dans ton exe. A part ça je voit pas ce qui pourrait le faire.

Citation:

---

Envoyé par dev01

Regarde du coté de Cecil afin d'intégrer le code de la lib dans ton exe. A part ça je voit pas ce qui pourrait le faire.

---

Mono.Cecil !? Il n'y a pas grand chose là dessus sur le Net. Et puis mettre en place une machine à gaz pour une chose... si évident !

Par exemple, quand on veut intégrérer des images dans l'executable car c'est mieux que de les laisser trainer... Il suffit pour cela de créer des ressources.

Mais pour une Dll... Pourquoi n'y a t'il rien pour nous simplifier la vie. Si les ressources internes existent c'est bien qu'il y a une utilité !?

Je vois donc qu'une solution pour la Dll : la mettre en ressource puis faire des appels par Reflexion.

Je ne peux donc pas garder mon code comme il était écrit avec une Dll externe. Puisqu'avec des appels dynamiques on doit faire "myMethod.Invoke(obj,truc)" au lieu de "obj.Method(truc)".

8O :( Il y a surement quelque chose qui m'echappe car je ne comprend pas pourquoi Microsoft n'aurait rien prévu pour ça.

Citation:

---

Envoyé par ijk-ref

Mono.Cecil !? Il n'y a pas grand chose là dessus sur le Net. Et puis mettre en place une machine à gaz pour une chose... si évident !

---

Si evident pour toi, mais absolument aucune utilité pour 99 % des développeurs ...
Et puis excuse moi mais Mono.Cecil est très très loin d'être une usine à gaz comme tu le dit. Tu as juste un petit outil à écrire qui injecterais ta lib dans ton exe rien d'autre.

Citation:

---

Envoyé par ijk-ref

Par exemple, quand on veut intégrer des images dans l'exécutable car c'est mieux que de les laisser trainer... Il suffit pour cela de créer des ressources.

Mais pour une Dll... Pourquoi n'y a t'il rien pour nous simplifier la vie. Si les ressources internes existent c'est bien qu'il y a une utilité !?

---

L'utilité est bien pour tout ce qui media mais une lib "doit" être externe pour la réutilisabilité, la gestion des version, l'enregistrement dans le GAC, etc, etc, ...

Citation:

---

Envoyé par ijk-ref

Je vois donc qu'une solution pour la Dll : la mettre en ressource puis faire des appels par Reflexion.

Je ne peux donc pas garder mon code comme il était écrit avec une Dll externe. Puisqu'avec des appels dynamiques on doit faire "myMethod.Invoke(obj,truc)" au lieu de "obj.Method(truc)".

---

Donc tu as ta solution mais elle te plait pas :-(

Citation:

---

Envoyé par ijk-ref

8O :( Il y a surement quelque chose qui m'echappe car je ne comprend pas pourquoi Microsoft n'aurait rien prévu pour ça.

---

parce qu'il n'y a aucune utilité à part des cas très très particulier ...

Citation:

---

Envoyé par dev01

parce qu'il n'y a aucune utilité à part des cas très très particulier ...

---

Il est fort probable que tu es plus raison que moi ;) N'empêche que je suis pas le 1er à mettre posé la question ("intégrer un Dll") vu le grand nombre de fois où je l'ai trouvé sur Google (sans réponses)

Tu veux dire qu'il est impossible de faire un simple programme d'installation en .NET (qui par définition ne doit pas avoir de lib externe) qui créer un lien (Shortcut) sur le Bureau sans utiliser la Refexion !?

Autrement je n'oublie pas de te remercier pour ta patience et la précision de tes réponses :D et j'espère que tu prends pas mes paroles pour arrogantes ;) c'est juste ma façon de m'exprimer et de poser mes questions. Merci encore

Salut,

je ne travaille pas souvent avec Com, donc ce qui suit est hautement hypothetique.

Pour fusionner deux assembly (la dll d'interop en est un non ?), il existe un outil de Microsoft qui fait le job : ILMerge. Ou meme en bidouillant son script de build à la main, pour créer un assembly mutli-module (Visual ne supportant pas ce genre de build à la base) .

Citation:

---

Envoyé par ijk-ref

Tu veux dire qu'il est impossible de faire un simple programme d'installation en .NET (qui par définition ne doit pas avoir de lib externe) qui créer un lien (Shortcut) sur le Bureau sans utiliser la Refexion !?

---

Je veux surtout dire qu'un programme d'installation s'il doit être autonome alors il ne faut pas qu'il soit dépendant du Fx .NET. Or à partir du moment ou tu développes en .NET tu as besoin du Fx .NET pour exécuter tes applications.

Citation:

---

Envoyé par ijk-ref

et j'espère que tu prends pas mes paroles pour arrogantes ;) c'est juste ma façon de m'exprimer et de poser mes questions. Merci encore

---

Absolument pas. y a aucun problème d'aucune sorte.Désolé si jamais mes réponses ont put d'amener à croire cela.

Citation:

---

Envoyé par SirJulio

Salut,
Pour fusionner deux assembly (la dll d'interop en est un non ?), il existe un outil de Microsoft qui fait le job : ILMerge. Ou meme en bidouillant son script de build à la main, pour créer un assembly mutli-module (Visual ne supportant pas ce genre de build à la base) .

---

:D ILMerge c'est exactement ce que je veux ! Merci.

Je vais aussi voir si je peux faire quelque chose du coté du script de build.

Autrement j'avais 'résolu' mon problème en intégrant mes Dll externes en ressource. Mon programme se recopiait dans un dossier temporaire avec ses Dll remises en externes et puis il se relancait (Process.Start(filename)) depuis ce nouveau dossier :aie:

Donc, :resolu: ?