Restriction de permissions pour une DLL

Bonjour.

Est-ce qu'il est possible, en C# 3.5, de gerer les permissions d'une DLL à partir du programme qui fait appel à cette DLL ?

Le scenario est le suivant : un plugin pour une application lambda sera téléchargé à partir d'une source distante configurable par l'utilisateur. Certes, on previent l'utilisateur qu'il ne doit configurer que des sources dont il a confiance, mais bon, rien ne dit qu'il va suivre les conseils... Du coup, est-ce qu'il est possible au moins d'enlever un certain nombre de permissions (ou bien c'est plus simple de verifier qu'ils sont bien enlevés dans l'assembly du DLL avant l'exécuter ?), ainsi que de restreindre l'accès disque dur à un ou plusieurs dossiers ?

PS. Je ne sais pas si c'est utile, mais en cas où, je precise que l'application même doit forcement tourner avec les permissions de l'utilisateur qui l'exécute, et doit pouvoir y accèder à beaucoup plus de choses.

Si c'est des plugins, et si c'est C# 3.5, pourquoi ne pas utiliser la méthode fournie par le framework pour gérer les addins et leurs autorisations ?
cf. http://badger.developpez.com/tutorie...framework-3-5/

Citation:

---

Envoyé par smyley

Si c'est des plugins, et si c'est C# 3.5, pourquoi ne pas utiliser la méthode fournie par le framework pour gérer les addins et leurs autorisations ?
cf. http://badger.developpez.com/tutorie...framework-3-5/

---

Pourquoi ? Parce que je ne savais pas que cela existe, tout simplement. ;)

Et bien merci beaucoup pour le lien !

Des mois après, je reviens sur ce sujet avec un feedback.

Pour ceux qui souhaitent, comme moi, restreindre les privilèges au niveau de l'exécution du code, réfléchissez dix fois avant d'utiliser les AddIns du framework.

Après avoir effectivement tinté d'implémenter la chose sur un projet de taille, l'équipe chargée de ce projet a fini par décider de refaire tout sans utiliser d'AddIns. Ceci pour plusieurs raisons.

• La raison principale, c'est que chaque modification doit être refaite minimum sept fois à la place de deux, et d'ailleurs il n'est souvent pas possible de faire des copiers-collers. Niveau extensibilité du code, c'est bien entendu une catastrophe, si les spécifications évoluent souvent, comme ce fut le cas en l'espèce.
• La deuxième raison : on a pas pu trouver un quelconque avantage d'utiliser les AddIns plutôt qu'une solution ordinaire. La restriction des privilèges sur le code, elle, peut très bien être faite sur les simples AppDomains.
• Finalement, les AddIns cachent un nombre important de pièges. Par exemple le fait d'être obligé de créer des dossiers avec les noms spécifiques pour les différentes librairies. Pour des projets spécifiques, ceci peut juste ne pas être acceptable. À noter que les AddIns reprennent toutes les pièges des AppDomains, comme par exemple l'impossibilité de mettre un System.Windows.Forms.Control dans un add-in pour ensuite l'ajouter à l'interface d'une fenêtre crée par l'application principale.

Au final, on a perdu des milliers d'euros juste pour avoir fait le mauvais choix des AddIns dès l'origine.

Dès lors, refaites pas la même erreur. Si vous voulez implémenter les plugins dans un logiciel, soyez bien sûr que les AddIns vous apportent quelque chose de précieux et indispensable qu'aucune autre approche ne peut apporter et que votre projet n'est pas Agile et ne subira aucune modification des spécifications.

Merci pour ton retour.