IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C# Discussion :

Question très spécifique: Migration de bibliothèque de classes


Sujet :

C#

  1. #1
    Membre éprouvé
    Profil pro
    Inscrit en
    juin 2008
    Messages
    609
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : juin 2008
    Messages : 609
    Points : 1 051
    Points
    1 051
    Par défaut Question très spécifique: Migration de bibliothèque de classes
    Salut
    ------
    J'ai une question très spécifique dont j'imagine que seules quelques personnes pourront avoir la réponse. Le problème est simple à comprendre mais long à expliquer, désolé.

    J'utilise dans des tas de projets depuis 2010 une bibliothèque de classe contenant des contrôles winforms personnels. Actuellement, la version est en framework 3.5.
    Pour l'utilisation, il me suffit, dans VS, d'ouvrir la boîte à outils (fenêtre quelconque en mode designer), de créer un nouvel onglet et d'y faire glisser ma dll et sa xml (intellisense) depuis le bureau.
    Et tous mes contrôles apparaissent dans l'onglet ajouté, avec leur icône, et sont parfaitement fonctionnels en mode design et en mode programmation.
    Ma dernière utilisation est un projet récent développé sous VS2019 en framework 4.8 et ça fonctionne toujours parfaitement.

    Par contre, maintenant je tente de créer en VS2022 un nouveau projet en .net6 (en .net5 c'est pareil, j'ai essayé): Si je glisse mes contrôles dans la boîte à outil, ils apparaissent avec leur icône mais en grisé (non activés) et j'ai un message disant qu'ils ne peuvent pas être activés sous cette version dotnet.
    Quelque part, c'est logique, on est sur un autre type de support.

    Donc, réaction logique, je décide de migrer mes contrôles en .net6 (ou 5): Pour faire un essai, je crée une nouvelle solution comportant un projet dll et un projet winform (pour tester les contrôles): Je crée un bête contrôle hérité de ComboBox, juste pour tester, je lui donne un nom et je surcharge simplement sa propriété BackColor pour avoir une visualisation du fonctionnement.

    Je compile, le contrôle apparaît dans la boîte à outils en tant qu'élément de la solution: Je mets la fenêtre en mode design et je peux glisser ce contrôle "personnalisé" dans la fenêtre et sa couleur de fond est bien remplacée: Donc, niveau principe, ça fonctionne sans le moindre problème comme en framework.

    Le problème survient lorsque j'ouvre une nouvelle solution winform .net6 et que j'y fait glisser, comme d'habitude, la dll obtenue dans la boîte à outils: Là, j'ai un "bing" d'avertissement et rien ne se passe, pas même le moindre message d'erreur ni même mon contrôle en grisé: Mon contrôle n'apparaît simplement pas, la dll n'est manifestement même pas reconnue.

    Bref, en .net6 (que je ne connais pas du tout) j'arrive à faire des composants personnalisés qui fonctionnent dans un projet qui fait partie de la même solution que mes contrôles, mais ma dll n'est plus "portable" dans une autre solution. Je ne vais quand même pas inclure le projet source dans chaque nouvelle solution .net6.

    J'ai du louper quelque chose au niveau de la compilation, mais j'ai fait des tonnes d'essais et je n'ai pas trouvé.

    Si quelqu'un a une idée sur la façon de créer une dll de contrôles et de la faire accepter dans une solution tierce, je suis preneur.

    Merci d'avance,
    Claude

  2. #2
    Expert confirmé
    Avatar de popo
    Homme Profil pro
    Analyste programmeur Delphi / C#
    Inscrit en
    mars 2005
    Messages
    2 227
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Analyste programmeur Delphi / C#
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2005
    Messages : 2 227
    Points : 4 255
    Points
    4 255
    Par défaut
    Sur le principe les deux ne sont pas compatibles. La manière de penser avec Core 6 n'est pas la même qu'avec .Net Framework
    Tu peux aussi avoir des problèmes si tu compiles en 32Bits.

    Mais il existe des solutions pour porter du Framework vers du code ou encore des packs de compatibilité.
    Regarde déjà ce qui peut t'intéresser dans ces deux liens

    https://learn.microsoft.com/en-us/dotnet/core/porting/
    https://learn.microsoft.com/en-us/ar...k-for-net-core

  3. #3
    Membre éprouvé
    Profil pro
    Inscrit en
    juin 2008
    Messages
    609
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : juin 2008
    Messages : 609
    Points : 1 051
    Points
    1 051
    Par défaut
    C'est très gentil de me répondre.

    Mon souci n'est pas que je n'arrive pas à porter mon code: Au niveau de la migration, aucun problème spécifique avec mon projet.
    Ce n'est pas non plus que je n'arrive pas à porter ma librairie de contrôles: Ça ne semble pas poser de problème. En fait j'ai même déjà migré plusieurs de mes contrôles et dans la solution créée ils fonctionnent parfaitement, même au niveau design (menus contextuels, alignements, localisation, intellisense etc.).

    Mon souci est au niveau de l'utilisation de la dll de contrôles personnalisés:

    Je crée une solution .net6 qui contient 2 projets: Une librairie de classes contenant un unique contrôle "personnalisé" qui est juste un composant dérivé de combobox pour lequel j'ai surchargé sa propriété backColor, et une fenêtre de "test" dans laquelle je vais placer ce contrôle.
    J'ai fait ça juste pour vérifier que tout fonctionne avant de tout migrer effectivement, parce que mes projets à migrer en framework 4.8 utilisent déjà ma librairie de contrôles en 3.5.

    Bref, en .net6, Je compile et j'ouvre le designer de la fenêtre du projet de fenêtre de test: J'ai la boîte à outils qui apparaît à côté de ma fenêtre, et mon contrôle dérivé de combobox s'y trouve comme "élément de la solution". Je le glisse sur ma fenêtre de test, il se place et fonctionne sans le moindre problème. Autrement dit, quand la librairie de contrôles et la fenêtre dans laquelle on va les utiliser sont dans la même solution, tout fonctionne sans problème.

    Donc, niveau ".net6", aucun souci, ma solution de test fonctionne et donc je peux migrer mes projets, ce qui nécessite de migrer également ma librairie de contrôles

    Le problème survient lorsque je crée une nouvelle solution contenant une fenêtre: J'ouvre le designer, je crée un onglet dans la boîte à outils, et, depuis mon bureau, je fais glisser la dll de mes contrôles personnalisés .net6 dans l'onglet créé de ma fenêtre .net6.
    Et là, j'ai un "bing", aucun message d'erreur, mais les contrôles de la dll n'apparaissent pas: Comme s'il manquait quelque chose au niveau de la compilation qui ferait que la dll n'est pas exportable dans une autre solution.

    Bref, si je veux utiliser ma dll de contrôle je suis contraint de charger tout le projet source de la librairie de classe dans ma solution: Là, ça fonctionne mais c'est tout sauf pratique, alors que jusqu'à présent (et c'est renseigné comme ça chez Microsoft), il suffisait de glisser sa dll dans la boîte à outils.

    Mon impression c'est qu'il manque quelque chose à ma dll pour être "autonome", j'ai cru voir passer qu'on pouvait compiler un projet de façon autonome ou nécessitant d'avoir le .net installé sur le PC: Seulement, je n'ai pas trouvé comment opérer, j'ai cherché dans les options de compilation, mais j'ai probablement du louper quelque chose.

    Ce qui est plus étrange, c'est que si je glisse dans cet onglet ma dll compilée en 3.5, j'ai un message d'avertissement m'indiquant que c'est incompatible et que mes contrôles seront désactivés (donc déjà j'ai un message), mais mes contrôles apparaissent tous (en grisé) dans l'onglet de la boîte à outils avec leur icone etc: Bref, avec ma dll 3.5 incompatible j'ai au moins quelque chose, mais rien du tout avec la dll en .net6 (ou 5).

    Je sais que c'est long à expliquer, désolé, mais en résumé: Ma dll fonctionne parfaitement lorsque je l'utilise dans une fenêtre située dans la même solution. Mais elle n'est pas utilisable dans une autre solution au niveau du fichier .dll

    Si tu as une idée, je suis preneur

    Je vais évidemment aller jeter un oeil dans tes liens, on ne sait jamais.

  4. #4
    Expert éminent sénior

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juillet 2016
    Messages
    2 696
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2016
    Messages : 2 696
    Points : 10 531
    Points
    10 531
    Billets dans le blog
    21
    Par défaut
    Question fort intéressante.

    Spontanément, je dirais que le problème vient de Visual Studio qui utilise le framework .Net (et non .Net Core). Mon interprétation (qui est peut être erronée mais me semble compatible avec le résultat observé) est la suivante :

    Pourquoi ça ne marche pas : la .dll utilise le .net6 (donc .net core) tandis que Visual Studio utilise le framework .Net. Visual Studio ne peut pas charger la dll et génère donc des erreurs (cryptiques, mais elles sont là).

    Mais du coup, pourquoi ça marche quand on est dans la même solution ? Parce que visual studio doit se baser non pas sur la .dll mais sur les sources qui sont de facto disponible (il le fait bien pour les tests, pourquoi ne le ferait-il pas pour ça ?).

    En bref, je pense que développer des composants en .Net 6 est faisable, mais que les intégrer ensuite dans le designer de visual studio n'est pas possible à cause de l'incompatibilité des cibles, sauf à intégrer directement les sources.
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  5. #5
    Membre éprouvé
    Profil pro
    Inscrit en
    juin 2008
    Messages
    609
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : juin 2008
    Messages : 609
    Points : 1 051
    Points
    1 051
    Par défaut
    Merci beaucoup,

    Je pense que c'est effectivement une possibilité, je n'y avais pas du tout pensé.

    Ce faisant, suite à ta réponse, j'ai refait une recherche à l'instant sur les langages de développement utilisés pour créer VS2022, en espérant tomber sur une confirmation avant de te répondre, et je suis tombé par hasard là-dessus:

    https://learn.microsoft.com/fr-fr/vi.../release-notes

    Ils y parlent explicitement de bugs sur l'ajout de dll personnalisées dans la boîte à outils qui ne fonctionnent pas. Résolus apparemment il y a 4 jours après plusieurs péripéties, si je suis les liens vers la communauté.

    Dès lors, je reviendrai préciser ce qu'il en est dès que j'aurais testé la nouvelle version.

    Encore merci
    Claude

  6. #6
    Membre éprouvé
    Profil pro
    Inscrit en
    juin 2008
    Messages
    609
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : juin 2008
    Messages : 609
    Points : 1 051
    Points
    1 051
    Par défaut
    Bon, j'ai effectué la transition.
    Maintenant, j'arrive à avoir un message d'erreur lorsque je tente d'ajouter ma dll comme composants de la boîte à outil, qui me dit que je tente de créer des ajouts dynamiquement dans une cible qui ne l'autorise plus.

    En cherchant, je tombe sur ceci:

    https://learn.microsoft.com/fr-fr/vi...t?view=vs-2022

    Où il est effectivement écrit:

    "Notez que dans Visual Studio 2019 et versions antérieures, plutôt que de répertorier les noms de contrôle de boîte à outils dans le manifeste, Visual Studio a énuméré dynamiquement les types de contrôle dans les assemblys du Kit de développement logiciel (SDK). À compter de Visual Studio 2022, cela n’est plus pris en charge ; Les éléments de boîte à outils doivent être répertoriés explicitement dans SDKManifest.xml."

    Bref, ça confirme le message d'erreur. Le souci vient donc d'un changement de stratégie explicite de VS2022 pour lequel, probablement, la solution d'ajouter à la volée sa dll était "trop simple".

    Maintenant on est contraint de modifier le SDKManifest.Xml: Mon souci c'est que j'en trouve plusieurs dans "program files/... Microsoft SDKs", mais aucun qui corresponde à ma config. Donc, il est où ce SdkManifest.dll?
    En outre, je ne comprends pas le principe car si je modifie globalement pour VS2022 et non pour ma solution spécifique, je crois comprendre que j'aurai mes contrôles même quand je n'en ai pas besoin, et, qu'à priori, si je modifie ce xml pour supprimer mes outils ils n'apparaîtront plus dans les projets qui en ont besoin.

    Là, j'avoue que je suis un peu perdu, j'imaginais avoir à éditer un fichier inclus dans ma solution (ce qui me semble logique). Sans compter que si je partage mon source, ça ne fonctionnera pas chez celui qui va le réceptionner... qui n'aura évidemment pas le même sdkManifest que moi dans program files.

    Je trouve ça curieux, et encore, il faudrait que j'arrive à faire fonctionner ça: Si quelqu'un sait comment faire, merci d'avance

  7. #7
    Membre habitué
    Profil pro
    Inscrit en
    septembre 2010
    Messages
    122
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : septembre 2010
    Messages : 122
    Points : 198
    Points
    198
    Par défaut
    Une des solutions c'est de publier ton composant, ça va te générer un package nuget, qu'il suffira alors d'ajouter à tes nouveaux projets via le gestionnaire de packet nuget
    Il faudra juste ajouter le chemin du paquet dans la liste de recherche du gestionnaire de packet Nuget (outils > options > Gestionnaire de package NuGet > Sources de package; clic sur le + et lui donner un nom et sélectionner le répertoire)
    Nom : nuget.PNG
Affichages : 30
Taille : 29,1 Ko

  8. #8
    Membre éprouvé
    Profil pro
    Inscrit en
    juin 2008
    Messages
    609
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : juin 2008
    Messages : 609
    Points : 1 051
    Points
    1 051
    Par défaut
    Merci de ta solution.

    Si je ne trouve pas une solution "intégrée", je publierai cette librairie.
    Pour l'instant je manque de temps, dès que possible je reviens sur ce problème et je reviendrai dire ce qu'il en est.

Discussions similaires

  1. Réponses: 6
    Dernier message: 28/07/2014, 11h09
  2. [VBA-E] comment créer une bibliothèque de classes ?
    Par james-mi dans le forum Macros et VBA Excel
    Réponses: 4
    Dernier message: 31/05/2006, 22h04
  3. [Tableaux] question très simple
    Par H-bil dans le forum Langage
    Réponses: 14
    Dernier message: 28/05/2006, 14h29
  4. Réponses: 3
    Dernier message: 28/04/2006, 12h27
  5. Question très bête : récupérer la valeur de retour d'une fct
    Par pekka77 dans le forum Général JavaScript
    Réponses: 7
    Dernier message: 28/10/2005, 18h57

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo