Discussion :

[megamario]

Bonjour à tous,


J'ai un petit souci et je sais pas vraiment encore vers quelle mécanique je dois me diriger.

ENVIRONNEMENT:

J'ai plusieurs logiciels qui utilise des licences. Chaque logiciels on des niveaux d’accès (USER/SUPER USER/ ADMIN / USINE) et la possibilité d'avoir 2 modes de licence, soit des clefs sous forme d'une série de chiffre alphanumérique, soit un Dongle sous la forme d'une clef USB. L'un n'est utilisable que sur un seul PC, l'autre pouvant donc être déplacer. En théorie, la Clef alpha est adapté au personnels Utilisateur pour de la visu, et les Dongles en admin pour les itinérant en maintenance par exemple, même si en pratique c'est pas vraimetn utilisé comme cela au final, mais bon sa n'est pas le sujet.


PROBLÈME:
Pour les Dongles j'ai pas trop de souci, l’interrogation est bloquante mais assez rapide, le Dongle étant prioritaire et pouvant être enlevé je l’interroge régulièrement, dans un thread a part afin de pas bloquer l'utilisateur. Par contre l'interrogation des serveurs pour la gestion de clef alphanumérique est plus problématique, car il prend entre 20 et 40 secondes a répondre. Je l'interroges qu'une fois, à l'ouverture du logiciel, mais cela bloque donc l’accès au logiciel le temps de savoir si la licence est encore valide. Bon si un Dongle est aussi présent sur le PC je passe rapidement en continuant à attendre la réponse de l'autre.
S'il n'y a pas de licence Alpha. de déclaré, mais seulement un Dongle, si l'utilisateur enlève le Dongle cela stop le logiciel après avertissement et 60 secondes.

IDÉE ENVISAGÉ:
Pour éviter ce temps d'attente au démarrage, mais aussi pour avertir un utilisateur que sa licence est périmée alors qu'il n'utilise pas encore le logiciel (cela arrive parfois qu'un utilisateur ai besoin sur site du logiciel et il s'aperçois que sa licence est périmée,même si je préviens 30 jours avant, si le client ouvre le logiciel durant cette période, cela ne semble pas suffire), je souhaiterais donc qu'un logiciel démarre avec Windows pour s'occuper des licences.
Ainsi lorsque l’utilisateur démarre le logiciel cela interroge celui qui gère les licences afin d'avoir une information rapidement (à voir la méthodologie pour cela et le cryptage a utiliser).
De plus en cas d'expiration l'utilisateur serait averti immédiatement même s'il n'utilise pas le logiciel en question.

QUESTION:
1)Quel type de logiciel utiliser pour la gestion des licences.
-Un service, mais cela semble difficile d’interagir ensuite avec l'écran de l’utilisateur.
-Donc je pensais plus à un logiciel démarrant en arrière plan avec Windows et se plaçant directement dans la barre de processus à coté de l'horloge. Mais cela ne semble pas natif en WPF.

2)La communication entre les logiciels et le service de licence.
-Utilisant des Sockets ou existe t'il un autre moyen intégrer dans le DotNet.


Subsidiaire)Il faut aussi que le client puisse, s'il préfère, n'utilise pas le service de licence au démarrage de Windows. Se serait donc plus long a lancer les logiciels, mais surtout plus d’alerte préventive.

[joKED]

Bonjour,

Ton idée envisagée parait cohérente. Avoir un service windows dédié au licensing, ce n'est pas déconnant. Il viendrait vérifier de manière régulière la présence ou non d'un dongle, ou interrogerait ton serveur de licence distant.
L'avantage, c'est qu'il peut démarrer avec windows, n'est dédié qu'à ça, tourne en fond et ne dérange personne, et est relativement contrôlable (en terme de mode de démarrage, récupération sur erreur, droits de fonctionnement).
Et créer un service windows, c'est assez trivial.

Pour la communication avec ton app, par socket oui, ou via WCF (ton service windows hébergeant ton service WCF).
WCF est pas forcément super simple à prendre en main, mais est (de mon point de vue qui n'engage que moi) plutôt robuste et très configurable.

Et en cas d'indispo du service windows de licence (volontaire de la part de l'utilisateur ou simple panne), à toi de prévoir un fallback vers interrogation du dongle ou du service distant (ça demande de dupliquer de la logique, mais c'est cohérent si ton app doit absolument fonctionner avec vérification de la licence).

[megamario]

Bonjour joKED,

Ton idée envisagée parait cohérente. Avoir un service windows dédié au licensing, ce n'est pas déconnant. Il viendrait vérifier de manière régulière la présence ou non d'un dongle, ou interrogerait ton serveur de licence distant.
L'avantage, c'est qu'il peut démarrer avec windows, n'est dédié qu'à ça, tourne en fond et ne dérange personne, et est relativement contrôlable (en terme de mode de démarrage, récupération sur erreur, droits de fonctionnement).
Et créer un service windows, c'est assez trivial.

J'ai trouvé un exemple pas mal du tout de l'utilisation d'un NotifyIcon en WPF sur CodeProjet, avec l'utilisation d'infobulle sympa (pouvant servir à donner une info à l’utilisateur sur l’état de la ou les licences une fois récuperés, Infobulle personnalisable annonçant une conformité ou une erreur par exemple, éventuellement l'introduction d'un Dongle etc...). l'infobulle peut être remplacé par les messages de notification présent dans Windows 10(faut que je vérifie la compatibilité avec les autres Windows dont le 7 encore beaucoup utilisé. Il y a bien sûr le menu contextuel et l'icone.

Bon malheureusement pour moi il est en C# (comme souvent) et j'ai quelques souci d'adaptation vers le VB. Cela ne me dérange pas pour la dll puisque que je ni touche pas, mais il fourni plusieurs exemple dont un "Windowless Sample" qui serait parfait comme démarrage de mon appli.

J'ai des souci avec l'adaptation DelegateCommand (de "NotifyIconViewModel"), mais je vais voir avec ce que je connais déjà pour l'adapter.

Pour la communication avec ton app, par socket oui, ou via WCF (ton service windows hébergeant ton service WCF).
WCF est pas forcément super simple à prendre en main, mais est (de mon point de vue qui n'engage que moi) plutôt robuste et très configurable.

Et en cas d'indispo du service windows de licence (volontaire de la part de l'utilisateur ou simple panne), à toi de prévoir un fallback vers interrogation du dongle ou du service distant (ça demande de dupliquer de la logique, mais c'est cohérent si ton app doit absolument fonctionner avec vérification de la licence).

Je n'est jamais utilisé de WCF, je vais regarder cela.

Merci beaucoup

[Pol63]

lu en diagonale
mais pour ton serveur mets 40 secondes à répondre une clé ? une seconde ca me parait déjà long pour un aller retour réseau ...
après pour dialoguer entre 2 processus sur une même machine il y a plus simple que wpf, je sais plus si c'est cannaux nommés ou mémoire partagé mais y en a un des deux ou en quelques lignes de code tu peux échanger des instance de classe
il y a des traducteurs de c# vers vb.net sur le net

[megamario]

lu en diagonale
mais pour ton serveur mets 40 secondes à répondre une clé ? une seconde ca me parait déjà long pour un aller retour réseau ...
après pour dialoguer entre 2 processus sur une même machine il y a plus simple que wpf, je sais plus si c'est cannaux nommés ou mémoire partagé mais y en a un des deux ou en quelques lignes de code tu peux échanger des instance de classe
il y a des traducteurs de c# vers vb.net sur le net

Bonjour Pol63,

C'est effectivement le temps qu'il met, surtout qu'il ne se connecte pas tout le temps.
Lors de la 1ere utilisation, la dll (qui nous est fourni, on a juste à la patcher avec nos paramètres, dont le profil utilisateur) n'a pas de licence, elle tente de se connecter à internet (Je dit elle tente, car cela fonctionne même sur un PC non connecter à l'aide d'un autre PC ou téléphone connecter à internet il y a des paramètres a s’échanger sous forme de grand code).
Le client donne ces coordonnées puis reçois un email de validation. Ensuite notre logiciel peut se lancer.
Mais une connexion a internet n'est demandé que tous les mois pour vérification (on peut le forcer bien sûr et c'est paramétrable)
Mais lorsque je demande à la dll les informations de sécurité (la licence) elle est bloquante pendant 30 secondes environ et là on est pourtant en interne.
C’était un peu plus rapide avec VB6, mais en Dotnet c'est long, trop long.


En faisant une appli qui démarre avec Windows au moins j'aurai plus ce problème et le client sera informé de la date de péremption de sa licence même s'il ne lance pas le logiciel. Un pierre 2 coup.
J'ai 7 profils de licence (logiciel) je fait donc 14 thread, 7 pour les licences WEB, et 7 pour les Dongles. Chaque profil n'aillant pas forcement la même date de fin, le même niveau d’accès etc...
Du coup maintenant en 30 secondes j'ai l’intégralité des profils des licences.

Mais je vais laisser le choix au client d'utiliser ce logiciel ou resté comme avant. Certains n'aime pas avoir une appli qui tourne tout le temps en arrière plan. Un autre choix possible, serait de fermer ce logiciel après avoir récupérer les infos et les afficher en info bulle. Bref je vais essayer de rester souple dans son utilisation.

-->Intéressant l’échange de classe, je vais creuser.

[Pol63]

ok ...

1)Quel type de logiciel utiliser pour la gestion des licences.

bah du custom
ca sert à quoi d'acheter une dll nulle pour faire un truc alors qu'avec quelques lignes de code on peut faire mieux ...

[megamario]

ok ...

bah du custom
ça sert à quoi d'acheter une dll nulle pour faire un truc alors qu'avec quelques lignes de code on peut faire mieux ...

Sincèrement je suis preneur. De plus ce n'est pas gratuit la solution.

[Pol63]

custom ca veut dire fait maison
donc ca veut dire que c'est à toi de le coder si tu le veux

donc il faut réfléchir, ce qui se fait couramment c'est de demander l'id du processeur, c'est lui qui sera identifiant de la machine (ca change pas souvent)
si tu lies ca à un client ca permet de lui refournir une clé s'il change de machine

après pour la clé soit c'est un générateur que tu créés (donc un algo qui permet de générer des clés et après de vérifier si elles sont valides), et la clé est envoyée sur le serveur pour pouvoir vérifier de temps en temps
soit la clé est un calcul à partir de l'id du processeur et dans ce cas tu même faire en sorte que ca fonctionne en déconnecté (avec le client qui te donne un code affiché à l'écran et tu lui en donnes un en réponse)
dans les 2 cas tu peux savoir si la clé est valide
au passage dans la clé que le client doit inscrire tu peux coder un DateTime nullable qui serait la date de fin, ce qui fait que tu peux avoir une clé qui marche à l'infini ou pour un an
pour tout ca le mieux est de travailler des octets