Bonjour Teodora,
Malheureusement, je ne parlais pas de dll natives, mais bien de dll CLR .Net, des class library standard (pour aller plus loin, je dirais même des UWP Class Library, donc on ne peut pas être plus proche du projet hôte en terme de framework).
De ce que j'ai pu comprendre, c'est une limitation du framework UWP qui ferme toutes les portes habituelles (celles dont on pouvait se servir en framework .Net standard comme dans les applications winforms, WPF ou sites ASP MVC).
Au même titre que les capabilities dans les UWP, Microsoft a décidé de brider au maximum les possibilités pour soi disant améliorer la sécurité des applications livrées sur le store. Or, force est de constater que la couche UWP est le futur de .Net puisqu'ils
se veulent multiplateformes et compagnie. Sauf qu'en faisant ça, ils enlevent toutes les possibilités que les développeurs avaient auparavant.
Exemple concret : on pouvait piloter l'allumage ou l'extinction de l'écran connecté au device sur n'importe quelle appli. Maintenant, avec UWP, on ne peut plus. Avant, je pouvais charger mes plugins (codés par mes soins dans le même framework que l'applicatif
hôte) par le biais de l'objet Assembly (Assembly.LoadFrom en spécifiant le chemin de la DLL) maintenant on ne peut plus qu'utiliser Assembly.Load qui attend le namespace complet du type qu'on veut charger ce qui sous entend qu'il faut que la DLL soit déjà
intégrée au projet (donc aucune modularité possible puisqu'on doit obligatoirement compiler le projet hote avec les plugins qu'on souhaite charger). MEF et MAF ont disparu. J'ai bien essayé avec Microsoft.Composition mais ça ne passe pas non plus.
Pourtant ce que je souhaite faire reste dans le B-A BA des applis modulaires avec plugins :
1 projet Hote (en UWP)
N projets Plugins (en UWP class library)
Le projet hote va chercher la liste de DLL présentes dans le repertoire plugins puis les charge une à une dans l'application hote. Ca se fait tout seul sur les autres couches .Net et pas du tout sur celle là.
Pour résumer, Microsoft a bridé les quelques fonctionnalités qui rendaient tout le système intéressant si tant est qu'on ne développe pas une application simple.
Si vous avez la possibilité de communiquer ce message à quiconque travaillant sur le socle UWP, je serais plus que ravi de converser avec pour lui donner mon avis car je pense que beaucoup (que dis-je, enormément) de personnes se détourneront du framework
.Net à cause de ça quand ils retireront définitivement les anciennes couches applicatives. Même chose pour Windows 10 IoT qui s'appuie aussi sur UWP. Personnellement, je travaille avec .Net depuis 10 ans et je commence à avoir de sérieux doutes quant à la
pérennité de ce framework.
Cordialement,
Steeve
