Je suis en train de développer un Shell Extension pour Windows (ContextMenuHandler et autres conneries d’explorer.exe), et j’ai évidemment souvent besoin de recompiler ma DLL.
Je me pose 2 questions, et j’ai du mal à trouver des pages sur le l’internet qui pourraient y répondre:
Est-ce qu’il faut résenregistrer/réenregistrer la DLL à chaque recompilation?
Je suppute qu’explorer.exe a un cache pour le chargement/déchargement des DLLs, et du coup, j’ai l’impression que des fois, il ne prend pas la toute dernière version… Est-ce qu’il y a des trucs à savoir, genre des outils pour vider le cache, ou forcer la mise à jour d’une DLL en mémoire, ou je sais quoi?
A priori, pas besoin de réenregistrer la dll… l’enregistrement ne rajoutant que des references. Sauf bien sur, si tu ajoutes des objets COM dans ton assembly. Mais le soucis, c’est effecitivement que ton explorer risque de pas reprendre en compte direct (pire, il risque de verouiller la dll et t’empecher de recompiler).
La solution de Tzim (bien qu’il a jamais fais ce genre de choses) ? demander une ouverture d’explorer.exe dans un process séparé (voir code regedit ci-dessous), et eventuellement, utiliser une copie d’explorer.exe. Copie que tu va attacher a VS pour le debug.
Sinon, si c’est pas top secret, chuis pas mal interressé par la methode : me faire une shellex perso, ca me tente bien pour pas mal de taches courantes.
Je viens de mater des exemples depuis codeproject, et tester au passage (sous whidbey, en x64). L’important, je pense, c’est de re-registrer ton assembly dans le gac, faudrait que je fasse plus de test.
Au passage, dans mes exemples, y’a certaines structures pour l’interop qui sont mal definies, genre des HANDLE et autres HWND traduits en uint. OK, ca marche ptet chez le gars qui a codé, mais sous x64, les handles, ils font 64bits. Donc regarde a ce que ca soit bien traduit en IntPtr.
Bon, je vois que tu codes en .net 1.1, donc ca a peu d’importance… mais ton handler passeras pas sous x64
Bon après avoir testé un peu, il semble qu’avec .NET, ça soit plus simple qu’en unmanaged. Je me rappelle avoir galléré avec regsvr32 du temps où j’avais fait une shell extension en C/C++, mais là, les FonctionsQuiVontBien™ en .NET doivent faire des refresh ou je sais quoi… à moins que mon cerveau ait empiré mes souvenirs…
Bref là j’ai juste à killer explorer.exe pour pouvoir recompiler (écraser la DLL, quoi), et ça semble bien marcher… J’espère que ça va durer…
A titre d’information, il y a un exemple dans le SDK .NET qui implémente un Shell Extension (ça s’appelle ShellCmd, c’est facile à trouver). Avis aux autres qui veulent s’amuser…
[quote name=‹ lordabdul › date=’ 4 Aug 2005, 19:05’]A titre d’information, il y a un exemple dans le SDK .NET qui implémente un Shell Extension (ça s’appelle ShellCmd, c’est facile à trouver). Avis aux autres qui veulent s’amuser…
[right][post=« 383310 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Vu. Mais c’est bien ce que je disais, les signatures sont pas bonnes, si tu veux que ca soit multiplateforme
Il me semble par contre que tu as intérêt à fixer le Guid des tes interfaces COM, ou de tes classes (si tu ne te soucies pas de travailler un peu comme en COM et que tu n’utilises pas d’attributs de contrôle de la génération automatiques d’interfaces COM). Sinon tu risques de fouttre pleins de merdes à chaque fois que tu réenregistres ton assembly dans le registre (pas dans la GAC hein, dans le registre). Il faut que Glop confirme, mais il me semble que regasm ne supprime pas les entrées correspondant aux versions antérieures si tu ne fixes pas le Guid des interfaces exposées à COM.
De mémoire, l’attribut à placer est [Guid(“un guid standard que tu peux générer avec tools -> generate Guid”)]
Ouaip, il vaut mieux guarder le meme GUID, mais de toutes façons, t’as 2 méthodes (RegisterServer et UnregisterServer) qui, si elles sont bien écrites, te guarantissent que ta base de registre est propre ou, au pire, reste stable quand tu enregistres/désenregistre ton extension sans arrêt.
