Je voudrais écrire des extensions shell pour personnaliser complètement l'affichage d'un dossier particulier, par exemple l'Assembly Cache Viewer (accédez à c: \ windows \ assembly et vous verrez ce que je veux dire). Quelles interfaces COM sont responsables de la fourniture de ces crochets? Mon 'spectateur' sera écrit en C# ...Rédaction d'une extension Windows Shell similaire à la visionneuse de cache d'assemblage
Merci!
Voici un article qui devrait vous mettre sur votre chemin:
extension du shell Windows avec des extensions d'espace de noms vous permet de créer des fonctionnalités personnalisées pour Windows Explorer. Une utilisation courante consiste à permettre à l'explorateur de présenter une liste d'éléments qui n'existent pas dans un dossier réel, mais qui résident en réalité dans un certain nombre d'endroits. La vue sur le dossier donne l'impression que ces éléments sont au même endroit, ce qui facilite leur gestion. Cet article illustre le processus de création extensions d'espace de noms de coquille personnalisée en utilisant C# et le .NET FRAMEWORK. [...]
J'ai essayé ce code ... et utilisé en appelant: ShellFolder.RegisterFunction (typeof (Class1)) ; Mais ça ne semble pas faire quoi que ce soit ... ça ne marche pas sur Vista? – Adam
Notez qu'il existe controversy about doing explorer extensions in .NET. Exemple de problème: Si vous ciblez .NET 2.0, votre extension ne fonctionnera pas dans les boîtes de dialogue de "fichier ouvert" affichées par les applications .NET 1.1. Un processus ne peut charger qu'une seule version de l'environnement d'exécution .NET.
Ce n'est pas seulement une question d'extension qui ne fonctionne pas; vous allez injecter une version particulière de l'environnement d'exécution .NET dans toute application qui utilise des boîtes de dialogue de fichiers. Ce sont de mauvaises nouvelles si l'application est une application non géré qui projetait sur le chargement d'un composant COM ciblant une version plus récente du moteur d'exécution .NET, etc.
modifier: comme expliqué dans le commentaire, cela a été résolu par le runtime .NET 4.0. Par conséquent, les extensions d'explorateur géré doivent toujours cibler .NET 4.0 ou version ultérieure.
Le dernier environnement d'exécution .Net 4.0 prend en charge le chargement côte à côte de l'exécution .Net 4.0 (et de TOUS les futurs runtimes) avec des runtimes .Net antérieures. Voir l'extrait suivant de http://msdn.microsoft.com/en-us/magazine/ee819091.aspx "Avec la possibilité d'avoir plusieurs runtimes en cours avec n'importe quel autre runtime, nous pouvons maintenant offrir un support général pour l'écriture gérée les extensions shell, même celles qui s'exécutent avec des applications arbitraires sur la machine. " – logicnp
Et le gagnant est: http://www.ssware.com/eznamespaceextensions/eznamespaceextensions.htm – Adam