Discussion :

[AJMont]

Bonjour à tous,

J'ai développé un progiciel pour une société en .NET Framework 4.8 XAML. Jusqu'ici tout va bien.
La société en question a une succursale et voudrait lui fournir le progiciel "rebrandé" pour cette marque.

La solution simple serait de dupliquer le projet et faire les modifs de rebrand dessus.

Mais dans la suite des Maj seront appliquées aux deux... Donc je devrais dupliquer lignes après lignes au fur et a mesure.

J'ai pensé à peut être splitter le projet en plusieurs : un core pour les parties communes et un projet pour tout ce qui est spécifique. Mais je n'arrive pas à faire communiquer correctement les jonctions entre les projets. Je n'ai pas trouvé comment faire appel à une view xaml d'un autre projet, ni comment accéder aux "control" depuis un autre projet... Bref, soit je me débrouille mal dans cette façon de faire (mon code ne serais pas assez MVVM?), soit c'est pas possible.

Est ce que quelqu'un a déjà rencontré cette situation? et trouvé une façon de faire? je suis preneur pour toute piste de ce côté, même si ca passe par beaucoup de refactorisation.

[Pol63]

en quoi consiste le rebranding ?
il y a fort à parier qu'il n'y ait pas à dupliquer les projets
si c'est juste 3 images qui changent ca se fait très facilement
si ce sont des fenetres qui sont différentes d'une appli à l'autre, ou des menus différents carrément c'est faisable en faisant une dll pour chaque marque, et en chargeant la bonne, et en utilisant la reflection pour exécuter le code dans celle ci

[AJMont]

en quoi consiste le rebranding ?
il y a fort à parier qu'il n'y ait pas à dupliquer les projets
si c'est juste 3 images qui changent ca se fait très facilement
si ce sont des fenetres qui sont différentes d'une appli à l'autre, ou des menus différents carrément c'est faisable en faisant une dll pour chaque marque, et en chargeant la bonne, et en utilisant la reflection pour exécuter le code dans celle ci

Il y a pas mal de texte sur le xaml et des tabitem qui diffèrent. Et sinon certains comportements spécifiques liés à des évent sur le xaml. Et bien sûr l'icone et le nom de l'app...

[AJMont]

si ce sont des fenetres qui sont différentes d'une appli à l'autre, ou des menus différents carrément c'est faisable en faisant une dll pour chaque marque, et en chargeant la bonne, et en utilisant la reflection pour exécuter le code dans celle ci

J'ai essayé ceci, mais je me retrouve avec des problèmes de dépendances cyclique. Je n'avais pas pensé à cette possibilité (multi-branding) quand j'ai pensé l'architecture de l'app. Du coup j'ai très peu de méthodes qui ne font pas référence à des spécificités "brandé"

Pour être plus spécifique:
les classes qui sont globales -> projet core (pas de problème. donc les projets brandés doivent faire référence au projet core)
les méthodes de mise à jour Bdd -> projet core ( mais elle font référence aux donnés serveurs spécifique donc : référence au projet brandé !!! référence cyclique)
un xaml de login global -> projet core (ce n'est pas brandé parceque certains utilisateurs sont multi-brand)
un xaml app -> projet brandé (chargement depuis le projet brandé....)
Bref... ce n'est que le début...

[champy_30]

en utilisant la reflection pour exécuter le code dans celle ci
Surtout pas, la réflexion pour charger des classes dynamiquement c'est non seulement une mauvaise idée mais c'est surtout un trou de sécurité béant.
En général la réflexion c'est pour faire des IDE , des explorateurs d'objet ... les autres usages (en production) sont à bannir.

Il faut commencer par faire un état des lieux exhaustif des spécificités de chaque marque et créer une interface commune.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
 public interface IBrand
{
        Image Logo { get; set; }
        string  Name { get; set; }
        string LongSpecificText { get; set; }
        Action SpecialXamlEventCallback { get; set; }
        DataTemplate SpecialTabItemTemplate { get; set; }
}

Implémenter cette interface autant de fois que tu as de client plus une implémentation par défaut.
C'est dans le processus de build (serveur de build ou simple script de setup) que l'implémentation seras remplacé par celle du client.

[Pol63]

la réflexion pour charger des classes dynamiquement c'est non seulement une mauvaise idée mais c'est surtout un trou de sécurité béant.

dans ce cas l'injection de dépendance est une faille de sécurité aussi ...

[champy_30]

dans ce cas l'injection de dépendance est une faille de sécurité aussi ...

Les services injectés sont d'abord enregistrés, leurs dll n'est pas chargé dynamiquement , pas de soucis pour faire de la réflexion sur TES objets, le soucis c'est quand tu commence à charger dynamiquement une DLL avec un AssemblyLoad pour y chercher des types qui implémente une interface particulière par exemple.