Discussion :

[ClaudeBg]

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

[popo]

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

[ClaudeBg]

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.

[François DORIN]

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.

[ClaudeBg]

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

[ClaudeBg]

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

[umfred]

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)

[ClaudeBg]

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.

[ClaudeBg]

Bon, j'ai eu un peu de temps pour revenir sur ce sujet.

Pour le package nuget, ça fonctionne pour VS2019 mais ça ne fonctionne plus pour VS2022: Sous VS2022 Je peux créer sans problème un package nuget pour ajouter un bouton dans le menu "outils", par exemple, mais pour placer des contrôles dans la boîte à outils ça ne fonctionne plus, même si Microsoft n'a pas jugé utile de corriger ses exemples. Le pack s'installe, est reconnu dans les packs installés, mais la fonctionnalité "toolbox" n'est plus autorisée dans la pratique.

Il faut impérativement passer par la création d'un SDK de fonctionnalités avec le composant "toolbox": Le problème c'est que l'exemple fourni par Microsoft ne compile pas (ou plus): Même en créant tout par défaut sans rien modifier on obtient une erreur de compilation non identifiée.

Bref, pas de solution en vue, faudra que je m'y replonge par la suite, sauf si quelqu'un trouve une solution.
Les exemples non mis à jour de Microsoft, la création d'un projet par défaut qui ne compile pas ou plus, l'impossibilité de recréer un Nuget sur VS une fois qu'on a installé VS2022 (le SDK qui se charge via l'installeur de VS2019 est indiqué "non disponible pour cette application" dès qu'on crée ce type de projet), les exemples foireux pour créer un SDK pour toolbox: Tout ceci n'est pas digne d'une société comme Microsoft, ça fait quand même "gras bricolage".

Changer quelque chose qui fonctionnait parfaitement depuis plusieurs générations de VS, pourquoi pas, même si l'intérêt est bof-bof, mais remplacer quelque chose qui fonctionne par quelque chose soit qui ne fonctionne pas, soit dont la documentation est "douteuse", c'est anormal.

Je crée des applications spécifiques orientées "communication hardware": J'ai besoin de mes contrôles personnalisés sinon je perds un temps fou: Donc, cette migration foireuse m'empêche de passer sous VS2022.

[Mat.M]

Pour le package nuget, ça fonctionne pour VS2019 mais ça ne fonctionne plus pour VS2022

quelle est la version de Visual Studio ?
Cela peut venir aussi d'un problème de licences.
Il y a des versions gratuites et des versions payantes vérifiez de votre côté.
Le lien ici
Sinon c'est vraisemblablement un problème "d'assembly" au niveau dll

[Noxen]

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

Je pense que le fichier SDKManifest.xml est un fichier inclus dans la library que tu as développée ou dans le package déployé et non un fichier global de Visual Studio.

[StringBuilder]

Bonjour,

J'ai longtemps utilisé des DLL partagées aussi dans mes projets : même si pour ma part il n'y avait pas de composants visuels, on reste je pense dans le même genre de problème.

Depuis quelques temps, j'ai résolu tout un tas de problèmes avec VS 2022 en incluant le projet plutôt que la DLL (bon, faut les sources, certes).

Les deux gros avantages sont :
- Si tu as besoin de modifier la librairie partagée, tu peux le faire directement depuis ta solution, sans devoir ouvrir un autre VS, recompiler, recopier la DLL et recharger la solution.
- Si tu utilises GIT, depuis quelques versions VS 2022 supporte d'avoir plusieurs sources GIT dans une même solution : ainsi les deux projets peuvent vivre leur vie chacun d'un coté.

Après, une solution crade que j'ai trouvé pour résoudre (partiellement) les problèmes de versions multiples de .NET, c'est de créer une solution par version de .NET nécessaire à mes projets. Ensuite, je colle tout le code dans des classes dédiées au code (pas dans les classes autogénérées lors de la création d'un UserControl ou d'un UserForm par exemple).
Puis avec mklink dans la console Windows je crée des inodes dans chaque projet de ces fichiers de classes : ainsi chaque projet dispose des mêmes fichiers de code, que je n'ai besoin de modifier qu'une seule fois.
Ensuite quand j'ai besoin de telle ou telle version de .NET je n'ai qu'à incorporer le projet de la bonne version dans mon code.
Pour les rares cas où j'ai du code spécifique à une version de .NET j'utilise au choix des classes dédiées (qui ne sont présentes que dans le projet spécifique à cette version) soit des symboles de compilation afin que chaque projet ne compile que ce qui est compatible avec sa version.

Ca marche pas trop mal. Après il y a peut-être (probablement) moyen de faire plus propre.

[popo]

Après, une solution crade que j'ai trouvé pour résoudre (partiellement) les problèmes de versions multiples de .NET, c'est de créer une solution par version de .NET nécessaire à mes projets.

Cela n'a rien de crade, c'est même la norme.
Je le répète, 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.
Les librairies disponibles ne sont pas les mêmes.

[ClaudeBg]

Merci pour les réponses.
Alors, dans l'ordre:

quelle est la version de Visual Studio ?
Cela peut venir aussi d'un problème de licences.
Il y a des versions gratuites et des versions payantes vérifiez de votre côté.
Le lien ici
Sinon c'est vraisemblablement un problème "d'assembly" au niveau dll

Ce n'est pas un problème de version, c'est indiqué explicitement chez Microsoft que dorénavant sous VS2022 et contrairement aux autres versions, l'énumération dynamique de contrôles au niveau de la boîte à outils ne sera plus fonctionnelle: Ils précisent qu'il faut dorénavant créer un SDK, c'est juste que leur exemple ne fonctionne pas.

Je pense que le fichier SDKManifest.xml est un fichier inclus dans la library que tu as développée ou dans le package déployé et non un fichier global de Visual Studio.

En fait ce manifest apparaît quand on crée un projet de type SDK incluant un nuget: Là on a le fameux SDKManifest.xml. Mais, encore une fois, l'exemple proposé par Microsoft ne fonctionne pas (erreur de compilation). Dans la création d'une dll il n'y a pas de manifest. Si je crée un nuget sans sdk de fonctionnalité tout fonctionne pour les éléments de VS (menus supplémentaires personnalisés etc) sauf pour la toolbox, et Microsoft précise que c'est normal à partir de VS2022 (sauf qu'ils n'ont pas revu leur doc à ce sujet). Et si je suis l'exemple fourni pour créer un SDK de fonctionnalité de création de contrôle personnalisé dans la toolbox (donc, pile-poil ce que je veux), j'ai beau suivre scrupuleusement le détail des opérations, ça mène à une erreur de compilation non référencée. Et même si je crée le projet vide sans rien modifier, ça mène à une erreur de compilation, alors que ce n'est que du code auto-généré.

Depuis quelques temps, j'ai résolu tout un tas de problèmes avec VS 2022 en incluant le projet plutôt que la DLL (bon, faut les sources, certes).

Oui, ça, ça fonctionne, je l'ai précisé dans un de mes précédents commentaires (excepté les icones des outils dans ce cas, mais bon...). C'est juste que je trouve "lourd" de recharger tout le projet de contrôles dans chaque nouvelle solution. Ça ne participe pas vraiment à l'isolation des projets et ça complique les choses lorsqu'on fait une mise à jour des contrôles. J'aurais aimé pouvoir faire comme j'ai toujours fait: J'intègre ma dll à la toolbox et je m'en sers. Mais bon, en dernier recours, ça reste une solution de dépannage.

Je le répète, 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.
Les librairies disponibles ne sont pas les mêmes.

Il n'y a aucun problème de compatibilité: Si je référence ma dll dans ma solution core ça compile sans problème et ça fonctionne sans problème, mes contrôles sont bien dans les fenêtres que j'ouvre et fonctionnent correctement. Si j'inclus les sources de mes dll dans ma solution, j'ai accès à mes outils en mode design à partir de la toolbox mais en tant que "éléments du projet". C'est juste que je n'arrive pas à faire apparaître mes contrôles dans la toolbox en tant qu'outils classiques. Et j'ai évidemment tenté de recompiler toute ma dll en core 6, j'ai obtenu une librairie fonctionnelle mais exactement le même souci d'intégration dans la toolbox. J'ai aussi tenté de créer juste un simple UserControl que j'intègre à la toolbox: Pareil, avec le source je l'ai en tant qu'élément de la solution, mais ça n'apparaît pas dans la toolbox en mode dynamique. Et finalement j'ai suivi la procédure qui part d'un projet SDK qui inclut la création d'un UserControl par défaut, juste pour créer le SDK en question pour tenter de l'inclure dans la toolbox: Mais, comme je le disais, même en laissant tout par défaut au niveau du projet, le code auto-généré produit une erreur de compilation: Dans le meilleur des cas j'ai une erreur dans la structure de nommage des chemins de fichiers, qui ne sont pas un sous-ensemble de l'ensemble des noms etc..., sinon j'ai simplement une erreur numérotée sans la moindre explication.

Avant, je prenais ma dll et mon xml (intellisense), je les "draggait" dans la toolbox et mes contrôles personnalisés apparaissaient et étaient utilisables à partir de la toolbox en mode design. Maintenant Microsoft explique que ce n'est plus autorisé et qu'il faut passer par un SDK dans lequel on énumère explicitement chacun des contrôles qui doit apparaître dans la toolbox, et dans quel onglet il doit apparaître: Je peux utiliser mes contrôles en les créant dynamiquement par code, mais je n'ai plus accès à ces contrôles en mode design, sauf en ajoutant le projet à la solution, auquel cas je les récupère mais en tant qu'élément de la solution. C'est réellement la stratégie d'ajout de contrôles dans la toolbox qui a changé, mais je ne trouve aucun exemple fonctionnel pour créer ce fameux sdk de fonctionnalité.

Bref, je voudrais juste un "bête" exemple qui crée un UserControl rudimentaire de base dans un SDK que je puisse installer pour que ce Usercontrol apparaîsse dans la toolbox. À partir d'un exemple comme ça je devrais pouvoir être dépannée. Mais je n'ai rien trouvé.

[popo]

Les extension à Visual Studio ne sont pas via des SDK mais mais des VSIX.
As-tu suivi les étapes de cette page ?
https://learn.microsoft.com/en-us/vi...l?view=vs-2022

Edit :
Essaie pour voir mais chez moi mais ça ne place rien dans la toolbox (mais ça compile et ça s'installe)

[ClaudeBg]

Bon,
Vu que pour l'instant j'ai un peu de temps, j'ai poursuivi mes expérimentations.
Rien ne fonctionnait malgré que je suivais exactement les exemples, aussi bien pour construire un VSIX que pour construire un SDK.

J'ai donc désinstallé VS2022 puis réinstallé -> Pareil
J'ai refait une xième fois le même projet, j'ai forcé la désinstallation des 2 nugets relatifs aux VSIX puis j'ai nettoyé le cache et reforcé le téléchargement.
Et là j'ai pu créer un VSIX qui apparaît dans VS2019 et dans VS2022 lorsqu'on crée un projet winform, mais uniquement si le projet est en framework, sinon ça n'apparaît pas.
J'ai vérifié le VSIX et en fait ça crée un projet référencé sous framework 4.5. et je ne vois aucune possibilité prévue pour changer.

Donc, j'ai avancé, je n'ai plus le problème initial mais maintenant je tombe sur un problème qui semble relatif à ce que Popo indiquait: VSIX compatible avec VS2022 mais pas avec core .6
Et pourtant j'ai construit le VSIX à partir de VS2022, donc ça aurait du être compatible, mais non.

Je vais relancer la méthode utilisant le SDK pour voir si je peux passé outre les erreurs que j'avais avant.

Édit: je viens de voir ton dernier message. Ton lien est celui que j'ai suivi pour créer un VSIX. Ça compile mais ça n'apparaît dans la toolbox que si le nouveau projet que tu crées est en winform sous framework: En winform sous .core ça n'apparaît pas.
Par contre, ça fonctionne si on crée des ajouts au menu plutôt que des contrôles de toolbox.

Concernant le SDK, c'est renseigné chez Microsoft que dorénavant il faut passer par là.
C'est renseigné dans cet exemple:

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

Il est précisé:

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.

C'est un peu contradictoire avec le fait que je viens d'arriver à ajouter des outils dans la toolbox via un VSIX ordinaire, à condition que le projet sois en framework: Tu as probablement pointé du doigt que le problème n'est pas VS2022, c'est plutôt le core .net. Sinon, je ne serais pas arrivé à créer un contrôle de la même façon qu'avec VS2019.
Tout ça n'est pas clair du tout.

Le problème c'est que lorsque je suis cet exemple j'arrive à une erreur de compilation. Mais bon, vu que j'ai tout réinstallé je vais retester.

Ici on voit aussi que pour les outils de la boîte à outils il faut passer par un SDK:
https://learn.microsoft.com/fr-fr/vi...s?view=vs-2022