Discussion :

[Gluups2]

Bonjour tout le monde,

Je n'ai jamais fait de C++ jusque là, habituellement je développe en C# avec Visual Studio Community 2022.

Je suis intéressé pour surveiller l'état de chargement de la batterie de mes oreillettes (particulièrement, si des fois elles venaient à se reconnecter alors qu'elles sont sensées charger leurs batteries).

Et j'ai trouvé là quelque chose qui d'après la présentation devrait aider :
https://www.codeproject.com/Articles...ices-discovery

Il y a un forum en bas de la page, mais je ne suis pas sûr que ça serait une bonne idée de déterrer ça au bout de 13 ans pour une question liée à mon manque d'expérience du langage.

Si la DLL avait été fournie dans le téléchargement je ne me serais pas embêté, je l'aurais utilisée telle quelle, mais j'imagine que des considérations de sécurité ont encouragé à ce que chacun compile pour son propre compte.

Sur la même ligne j'ai deux fois l'erreur C1083 :

Gravité Code Description Projet Fichier Ligne État de la suppression
Erreur C1083 Impossible d'ouvrir le fichier include*: 'ceconfig.h'*: No such file or directory WMBluetoothWrapper1 C:\Projects Visual Studio\Winform\WMBluetoothWrapper\WMBluetoothWrapper1\stdafx.h 20

Selon une rapide recherche ce fichier est supposé être généré pendant la compilation, donc c'est qu'une autre opération s'est mal passée.
Je parie que quelqu'un qui bouffe du C++ toute la journée va me fournir l'explication en moins de deux sans forcer.

Une petite précision complémentaire, le projet WMBluetoothWrapper fourni dans le ZIP n'était pas compatible avec Visual Studio 2022, alors j'ai créé un nouveau projet, et j'y ai "ajouté" une copie de tout ce qui était dans le répertoire de l'ancien projet.

[bacelar]

Bon bin, le VS 2022 Community fraichement installé n'a pas été capable de convertir cette solution en quelque-chose de chargeable.

Vous devez avoir de vieux VS ou Plateform SDK d'installer sur votre machine, non ?

Les messages d'erreur de conversion ainsi que le texte de l'article font référence aux plateformes WinCE et WindowsMobile.
Ce sont des plateformes qui ont été abandonnées depuis plus de 10 ans par Microsoft.

Le message d'erreur indique l'absence du fichier "ceconfig.h", "ce" pour "Compact Edition" : WinCE.
"config.h", généralement, c'était une vielle méthode pour coller tout un tas de constantes de compilation dans un seul fichier, pour piloter la configuration cible et la construction du binaire.

Vous devriez changer la/les plateforme(s) cibles du projet de construction de la Dll pour qu'il cible une plateforme plus "actuelle".
Si le projet est bien fait, cela changera les fichiers ".h" utilisés et donc du besoin de trouver un fichier "ceconfig.h", pour un "config.h" vraisemblablement.

Une petite précision complémentaire, le projet WMBluetoothWrapper fourni dans le ZIP n'était pas compatible avec Visual Studio 2022, alors j'ai créé un nouveau projet, et j'y ai "ajouté" une copie de tout ce qui était dans le répertoire de l'ancien projet.

GG, plus débrouillard que moi, mais il vous manque le SDK correspond à WinCE.

Je ne vois pas trop d'adhérences à WinCE dans le code source.

Je reviens vers vous après avoir appliqué votre astuce.




P.S.: Après utilisation de votre astuce, le problème est dans "stdafx.h" qui est customisé en dur pour une compilation pour WinCE.

Comme je ne vois pas d'adhérences, faites un projet C++ Dll vierge et ajouter via copier-coller la déclaration et la définition de "extern "C" int DevicesDiscovery(wchar_t * devicesList)" dans le .h et le .cpp principaux.

Vous compilez, en ajoutant les #include qui manquent (mais pas ceux de WinCE).

Voili.

Sinon, il semble qu'il y ait un package Nuget qui existe depuis très longtemps et qui semble toujours maintenu pour la connectivité BlueTooth :
https://www.nuget.org/packages/InTheHand.Net.Bluetooth/

[Gluups2]

Bon bin, le VS 2022 Community fraichement installé n'a pas été capable de convertir cette solution en quelque-chose de chargeable.

Vous devez avoir de vieux VS ou Plateform SDK d'installer sur votre machine, non ?

Pour dire à quel point ... J'ai un peu eu la poisse (et le vendeur avec) avec les disques durs, le SSD a lâché, ce qui fait qu'il a été remplacé sous garantie, et que par la même occasion on en a profité pour m'installer Windows 11 (j'avais échoué trois fois à faire la migration depuis Windows 10).

Ça fait que ... la machine, avec son SSD et son système tout neufs, est là depuis moins d'un mois.

Et du coup, Visual Studio a été installé après.
J'aurais bien essayé de trouver le programme d'installation dans mes sauvegardes, mais pas de succès, j'ai fait un téléchargement tout neuf. J'ai dépassé mon forfait télécom, mais ça c'est une autre question.

Et pour ce qui est du SDK adapté au projet, comme il n'y était pas, il a donné lieu à une demi-heure de téléchargement juste pour ce projet.

Voilà, donc vieux ... Je sais bien qu'une machine qui sort juste de l'usine est obsolète, mais enfin là, c'est jusqu'à un point.

Les messages d'erreur de conversion ainsi que le texte de l'article font référence aux plateformes WinCE et WindowsMobile.
Ce sont des plateformes qui ont été abandonnées depuis plus de 10 ans par Microsoft.

Le message d'erreur indique l'absence du fichier "ceconfig.h", "ce" pour "Compact Edition" : WinCE.
"config.h", généralement, c'était une vielle méthode pour coller tout un tas de constantes de compilation dans un seul fichier, pour piloter la configuration cible et la construction du binaire.

Vous devriez changer la/les plateforme(s) cibles du projet de construction de la Dll pour qu'il cible une plateforme plus "actuelle".
Si le projet est bien fait, cela changera les fichiers ".h" utilisés et donc du besoin de trouver un fichier "ceconfig.h", pour un "config.h" vraisemblablement.

En effet, que le projet que j'ai téléchargé soit vieux, lui, ça c'est possible.
En fait, j'ai retenu le premier résultat de recherche, souvent sur codeproject ça baigne. Mais c'est vrai qu'il peut y avoir des exceptions.

À part ça j'ai un peu une idée, sous C#, de la différence entre .Net Core et .Net Framework, mais ce sont mes premiers pas autant sous C++ qu'en développement pour téléphone portable.
Donc pour choisir une plateforme de remplacement, je ne plaide pas spécialement compétent.
Le plus joli, c'est que j'ai une DLL à compiler, et il est bien possible que je n'y toucherai plus ensuite.

Donc là il y a deux pistes possibles, ou on réussit à tout faire dans les règles pour compiler ce projet, ou on trouve un autre projet qui permette de piloter le niveau de batterie des périphériques Bluetooth présents. Après tout, c'est vrai qu'en 13 ans on ne peut pas exclure que quelqu'un d'autre s'y soit intéressé. Si c'est comme ça que ça finit, c'est vrai que c'est ballot d'avoir une nouvelle fois dépassé mon forfait télécom pour installer le SDK.

GG, plus débrouillard que moi, mais il vous manque le SDK correspond à WinCE.

Je ne vois pas trop d'adhérences à WinCE dans le code source.

Je reviens vers vous après avoir appliqué votre astuce.

OK merci. Euh, mon astuce, c'est la création d'un projet ?

Je n'ai pas eu trop le choix, à vrai dire.

P.S.: Après utilisation de votre astuce, le problème est dans "stdafx.h" qui est customisé en dur pour une compilation pour WinCE.

Comme je ne vois pas d'adhérences, faites un projet C++ Dll vierge et ajouter via copier-coller la déclaration et la définition de "extern "C" int DevicesDiscovery(wchar_t * devicesList)" dans le .h et le .cpp principaux.

Vous compilez, en ajoutant les #include qui manquent (mais pas ceux de WinCE).

Voili.

Urgh, j'ai l'impression que pour une première initiation à C++, c'est pêchu.
D'habitude, on a coutume de commencer par un "Hello, world !" sur les plateformes par défaut.

Sinon, il semble qu'il y ait un package Nuget qui existe depuis très longtemps et qui semble toujours maintenu pour la connectivité BlueTooth :
https://www.nuget.org/packages/InTheHand.Net.Bluetooth/

Ah, la deuxième piste que j'évoquais, alors ?
Bon, je vais regarder ça. Ce soir pas sûr, mais bientôt.

Merci.

[bacelar]

Pour dire à quel point ...
...
... Je sais bien qu'une machine qui sort juste de l'usine est obsolète, mais enfin là, c'est jusqu'à un point.

Désolé, j'avais cru au départ que vous aviez réussi à migrer la solution et pas utiliser l'approche Frankenstein de coller le code dans un nouveau projet.

En utilisant l'approche Frankenstein, j'ai bien reproduit votre message d'erreur.

En utilisant l'approche Frankenstein, après avoir mis plus de 50% du code en commentaire, car ne servait que pour WinCE/Afx/MFC ; changer quelques #include pour prendre les versions "Desktop" et non WinCE des fichiers d'en-tête (<winsock2.h>, <windows.h>, etc... et pas de <ceconfig.h> et autres cochonneries) ; bidouiller l'ordre des #include pour que la nouvelle approche des fichiers d'en-tête précompilés de Visual Studio colle avec l'ancienne (pch vs stdafx) ; en changeant quelques type de variable qui semblent être des erreurs de typo ( ou des alias de types spécifiques à WinCE ?) ; changer des constantes de compilations pour que le compilateur ne gueule pas sur l'utilisation de fonction "boite à bugs/trou de sécurité" ; et configurer les options de l'éditeur de lien pour qu'il obtiennent les .lib nécessaires : j'ai généré une version Desktop/Win11 de cette Dll ; que je n'ai pas pu testé faute d'un programme client de cette Dll.

Donc, le code "utile" (ce qui est présenté dans l'article de CodeProject) n'a pas d'adhérence à WinCE, mais alors tout ce qu'il y a autour, mamma mia !!!, c'est fait à l'arrache comme un sagouin.

mais ce sont mes premiers pas autant sous C++ qu'en développement pour téléphone portable.

Ok, c'est pour cela que je ne vous donne pas ma version "Desktop" bricolée à l'arrache. (Mais ça casse pas 3 pattes à un canard quand on connait un peu le C++ mais surtout les spécificités Microsoft/Windows).
Ne devriez-vous pas passer par un Plateforme SDK dédié à ce téléphone portable plutôt que de réinventer une roue carrée ?

En l'état, la valeur ajoutée de cette Dll est très faible. Vous passerez bien plus de temps à apprendre à maitriser la compilation C++ sous Windows qu'à analyser/maitriser le code source.

Donc pour choisir une plateforme de remplacement, je ne plaide pas spécialement compétent.

une plateforme de remplacement ???

Le plus joli, c'est que j'ai une DLL à compiler, et il est bien possible que je n'y toucherai plus ensuite.

Ça, c'est sur le papier, quand le code est bien propre, sans adhérence en dur avec une plateforme morte depuis plus de 10 ans.
C'est quoi votre plateforme cible ?

Donc là il y a deux pistes possibles, ou on réussit à tout faire dans les règles pour compiler ce projet,

De base, ce projet ne suit pas trop les "règles de bonne conduite".

ou on trouve un autre projet qui permette de piloter le niveau de batterie des périphériques Bluetooth présents.

Vous avez jeté un œil sur le package NuGet "InTheHand.Net.Bluetooth" qui semble maintenu depuis plus de 10 ans ?

OK merci. Euh, mon astuce, c'est la création d'un projet ?

Oui, c'est tellement improbable d'avoir un truc qui fonctionne rapidement à partir d'un "vrai" projet que je n'avais pas pensé à cette "astuce".

Je n'ai pas eu trop le choix, à vrai dire.

Pourquoi ????

Urgh, j'ai l'impression que pour une première initiation à C++, c'est pêchu.

Une Dll de wrapping entre du natif et managé, sur une plateforme "embarquée" obsolète depuis 10 ans, codé à l'arrache, sur un IDE de la même époque avec du code C++98 (de bien avant 1998) alors qu'il y a déjà eu 5 normes depuis (C++03; C++11; C++14; C++17; C++20) et que la nouvelle version de l'IDE doit déjà implémenter une version de travail de C++23 (sans compter les versions des OS et autres framework .NET, etc...), c'est un peu "raid".

D'habitude, on a coutume de commencer par un "Hello, world !" sur les plateformes par défaut.

Oui, vous auriez dû commencer par ça.

Je peux vous poster ma "correction à l'arrache" mais le principale n'est pas dans le code source (configuration du projet, etc...) et si ce n'est pas pour du "Desktop", c'est pas trop utile.

[Gluups2]

Bonjour,

Euh, j'ignorais que la méthode de créer un projet là où celui fourni au départ est rejeté par Visual Studio s'appelât méthode Frankenstein, mais c'est bien celle que j'ai utilisée, faute d'en avoir une autre.

Alors quelques petites précisions à apporter.

Je n'ai pas de téléphone portable sur lequel programmer. Enfin bon mon téléphone tourne sur Androïd, mais je suis obligé de désactiver tout ce qui utilise Internet, sinon au bout de vingt minutes il me dit que mon forfait est épuisé, alors que je n'ai pas utilisé Internet DU TOUT. Donc, pour récapituler, j'ai un téléphone que j'ai acheté 100 euros, et dont je fais le même usage qu'un autre que j'ai acheté 20 euros. Meuh non, je ne me suis pas fait avoir.

J'ai un ordinateur avec Windows 10 professionnel, et une paire d'oreillettes Bluetooth.

Les oreillettes sont de chez Jabra, c'est du bon matériel, en tout cas comparé à tout ce que j'ai essayé avant. C'est vrai que ce n'était pas le même prix aussi.

J'ai quand même un petit souci avec, il arrive parfois qu'après que j'aie posé la veille les oreillettes dans leur boîtier de chargement, je les trouve avec un niveau de charge de 5%. Heureusement en vingt minutes on arrive à 80%, mais quand même, après une nuit, j'attends 100%, pas 5.

Surtout que tant qu'à faire, quand je passe juste un coup de fil pour savoir si il reste du pain (un exemple qui me passe par la tête ; exemple bidon puisqu'il y a une boulangerie en bas de chez moi), là le niveau de charge est bon. Non, c'est quand arrive l'heure d'une conférence en ligne prévue depuis une semaine, que le niveau de charge est à 5%. Content, je suis, à ce moment-là.

C'est pour ça que j'aimerais avoir un programme pour me prévenir quand le matos ne se comporte pas comme attendu. Par exemple, si un niveau de charge est annoncé, alors que la charge est en cours. Lorsque la charge est en cours, les oreillettes ne sont pas supposées être connectées, donc on ne doit pas pouvoir savoir leur niveau de charge. Si ça arrive, il faut sonner pour que je remédie au problème. Bouger un peu les oreillettes dans leur boîtier en général fait l'affaire, mais si c'est fait au moment où le problème se pose, pas au moment où on a besoin de ces joujoux. (Oh mince, hibou caillou joujou pou, j'avais oublié.)

Alors, c'est pour ça que j'ai mené une recherche sur "Bluetooth battery level", et je suis tombé sur ce projet.

Donc ... écrire un programme "Hello World !" en C++ que je n'ai jamais pratiqué, et où je ne sais pas quelles dépendances déclarer ni pour quel usage, juste pour surveiller la charge de batterie de mes oreillettes, je me demande si ce n'est pas légèrement surdimensionné.

Parfois les résultats des moteurs de recherche sont bons. D'autres fois, on a de sales surprises, comme là.
Il arrive que sur des fils de forums, quelqu'un propose de supprimer le fil car il est en doublon. Ah oui sauf que l'original, le moteur de recherche n'en a jamais entendu parler, c'est là que je suis arrivé, alors même si il y a un autre fil, je solutionne mon problème avec celui que quelqu'un voulait supprimer.

Bon, je vais regarder les résultats suivants, alors ?

Tant pis pour la demi-heure de connexion ...

J'espère que quelqu'un a proposé un projet plus probant.

Ah oui je me rappelle que tu as parlé de quelque chose sur NuGet.
Ça doit valoir un coup d'œil.
Oh, oh, je me demande bien pourquoi ma touche i s'est escrimée à taper des m pendant une minute. Ça s'est arrêté quand j'ai appuyé deux fois sur la touche Windows. La semaine dernière, E-Set a dit que la machine n'était pas infectée. Depuis il a surveillé qu'il n'y avait rien de louche.

Oh là, mais je n'ai pas encore dormi à cette heure-là ?
Hum, je crois que j'ai une petite idée de ce que je vais faire avant d'aller sur Nuget, moi.

[bacelar]

Euh, j'ignorais que la méthode de créer un projet là où celui fourni au départ est rejeté par Visual Studio s'appelât méthode Frankenstein, mais c'est bien celle que j'ai utilisée, faute d'en avoir une autre.

Je donne cet adjectif de Frankenstein à ce procédé car un projet ne se résume pas qu'à son code et avec cette manière de faire, c'est comme transplanter la partie code d'un projet dans un autre projet => un peu comme la bête de Frankenstein qui est constitué de corps humains rapiécés.

Je n'ai pas de téléphone portable sur lequel programmer.

Qu'entendez vous "sur lequel programmer" ?
Les environnements de développement sont rarement fait pour tourner sur un téléphone.
Généralement, on développe sur une machine pour générer un exécutable/script/... qui n'a pas forcement à fonctionner dans l'environnement de développement, exemple : cross-compilation.

Pour le développement sur téléphone, généralement, on développe sur Windows/Linux/MacOS pour générer un machin qui fonction sur le dit téléphone ( et/ou sur un émulateur du dit téléphone).

Enfin bon mon téléphone tourne sur Androïd, mais je suis obligé de désactiver tout ce qui utilise Internet, sinon au bout de vingt minutes il me dit que mon forfait est épuisé, alors que je n'ai pas utilisé Internet DU TOUT. Donc, pour récapituler, j'ai un téléphone que j'ai acheté 100 euros, et dont je fais le même usage qu'un autre que j'ai acheté 20 euros. Meuh non, je ne me suis pas fait avoir.

Sur Androîd, il est possible de voir la consommation de données application par application.
Certaine application ont la réputation de "bouffer de la data" en arrière-plan comme Messenger de Meta/Facebook.
Vous pouvez donc savoir quelles applications bouffent votre forfait data et les restreindre à n'utiliser les données que si elles sont "devant", d'utiliser un mode "économie de données", voir les désinstaller pour les remplacer par des applications moins gourmandes et/ou plus respectueuses de vos choix et contraintes.
Vous avez le pouvoir, même sans rooter votre téléphone.

J'ai un ordinateur avec Windows 10 professionnel, et une paire d'oreillettes Bluetooth.

On va donc dire que la cible de votre programme est un Win10 ? (donc une application Descktop ?)

Les oreillettes sont de chez Jabra, c'est du bon matériel, en tout cas comparé à tout ce que j'ai essayé avant. C'est vrai que ce n'était pas le même prix aussi.

En demandant à notre ami Google : "Jabra SDK"
On obtient des réponses des plus intéressantes pour commencer des développements pour ce type d'accessoire :
https://developer.jabra.com/site/global/home/index.gsp
https://developer.jabra.com/site/global/sdk/index.gsp

Comme vous le voyer .NET est l'un des environnements possibles pour ces développements.

Alors, c'est pour ça que j'ai mené une recherche sur "Bluetooth battery level", et je suis tombé sur ce projet.

Si votre projet n'a pas à être "générique" (plusieurs fabriquant, plusieurs modèle, ...), je vous conseille de faire des recherche plus ciblées.
Requête Google :"Jabra SDK Bluetooth battery level"
https://developer.jabra.com/site/glo...attery-low.gsp
Il semble donc avoir des moyens très simple, mais peu "portable" de faire la chose.

[Gluups2]

Je donne cet adjectif de Frankenstein à ce procédé car un projet ne se résume pas qu'à son code et avec cette manière de faire, c'est comme transplanter la partie code d'un projet dans un autre projet => un peu comme la bête de Frankenstein qui est constitué de corps humains rapiécés.

Il y a un peu de ça ...
Après avoir téléchargé un projet qui remonte à quelques années, ça m'est arrivé d'avoir à jouer à ça, d'habitude ça fonctionne mieux que ça.

Pour le développement sur téléphone, généralement, on développe sur Windows/Linux/MacOS pour générer un machin qui fonction sur le dit téléphone ( et/ou sur un émulateur du dit téléphone).

Je connais le principe, mais je n'ai jamais vraiment appliqué.
Ça pourrait être intéressant d'essayer, mais pour le moment je suis très à la bourre sur Angular, alors je vais plutôt commencer par ça.

Sur Androîd, il est possible de voir la consommation de données application par application.

Et de bloquer ce dont on n'a pas besoin, aussi ?

Je ne me rappelle plus trop, le caractère caricatural de l'excès de consommation inutile m'a dissuadé d'y revenir depuis un moment.

Vous avez le pouvoir, même sans rooter votre téléphone.

Orange a proposé un coup de main, alors quand j'arriverai à être un peu disponible ...

On va donc dire que la cible de votre programme est un Win10 ? (donc une application Descktop ?)


En demandant à notre ami Google : "Jabra SDK"
On obtient des réponses des plus intéressantes pour commencer des développements pour ce type d'accessoire :
https://developer.jabra.com/site/global/home/index.gsp
https://developer.jabra.com/site/global/sdk/index.gsp

Comme vous le voyer .NET est l'un des environnements possibles pour ces développements.

Ah oui, fort. J'ai demandé au SAV si ils avaient un tuyau là-dessus (en précisant même que la doc des API me suffirait), et ils m'ont envoyé bouler, pour eux les oreillettes c'était juste pour les smartphones.

Apparemment j'ai quand même fini par taper aux bonnes portes.
J'ai eu un peu de mal à installer le composant NuGet (c'était un coup ça qui était en panne, un coup la boîte à outils qui était vite, un coup autre chose ... Pour le moment ça a l'air d'aller, touchons du bois.)

Si votre projet n'a pas à être "générique" (plusieurs fabriquant, plusieurs modèle, ...), je vous conseille de faire des recherche plus ciblées.
Requête Google :"Jabra SDK Bluetooth battery level"
https://developer.jabra.com/site/glo...attery-low.gsp
Il semble donc avoir des moyens très simple, mais peu "portable" de faire la chose.

Ça ressemble à la requête que j'ai tapée, peut-être aurais-je dû préciser Windows.
Maintenant que le composant NuGet est en place ... il ne me reste plus qu'à m'asseoir devant

Merci pour les tuyaux.

[bacelar]

Ça pourrait être intéressant d'essayer, mais pour le moment je suis très à la bourre sur Angular, alors je vais plutôt commencer par ça.

Je ne vous pas le rapport entre Angular et la cross-compilation.

Et de bloquer ce dont on n'a pas besoin, aussi ?

On peut bloquer application par application.
Mais une application qui n'a pas besoin d'Internet pour travailler, c'est rare.
La Torche, des jeux de réflexion, pas beaucoup plus.
Vous pouvez interdire à une application d'utiliser Internet si elle n'est pas "affichée".

Je ne me rappelle plus trop, le caractère caricatural de l'excès de consommation inutile m'a dissuadé d'y revenir depuis un moment.

Ces données, c'est le pétrole des GAFAM.

Ah oui, fort. J'ai demandé au SAV si ils avaient un tuyau là-dessus (en précisant même que la doc des API me suffirait), et ils m'ont envoyé bouler, pour eux les oreillettes c'était juste pour les smartphones.

Les SAV pour consommateurs ne sont pas formés pour ça.
Le support aux développeurs, c'est via des canaux de communications dédiés (mailing-list ou forum dédiés, etc...)

J'ai eu un peu de mal à installer le composant NuGet (c'était un coup ça qui était en panne, un coup la boîte à outils qui était vite, un coup autre chose ... Pour le moment ça a l'air d'aller, touchons du bois.)

Aïe, malheureusement, il est assez commun que les NuGet des projets soient mal foutus.

Maintenant que le composant NuGet est en place ... il ne me reste plus qu'à m'asseoir devant

Je ne sais pas s'il y a sarcasme ou pas.

[Gluups]

Je ne vous pas le rapport entre Angular et la cross-compilation.

Juste que c'est difficile de faire les deux en même temps.

On peut bloquer application par application.
Mais une application qui n'a pas besoin d'Internet pour travailler, c'est rare.
La Torche, des jeux de réflexion, pas beaucoup plus.
Vous pouvez interdire à une application d'utiliser Internet si elle n'est pas "affichée".


Ces données, c'est le pétrole des GAFAM.

Raison de plus pour fermer le robinet.

Les SAV pour consommateurs ne sont pas formés pour ça.
Le support aux développeurs, c'est via des canaux de communications dédiés (mailing-list ou forum dédiés, etc...)

On dirait. Qu'est-ce que ça m'aurait fait gagner comme temps, qu'ils puissent m'envoyer là.

Aïe, malheureusement, il est assez commun que les NuGet des projets soient mal foutus.


Je ne sais pas s'il y a sarcasme ou pas.

Je ne sais pas encore ce que vaut celui-là, je n'ai pas passé assez de temps dessus pour me permettre d'être sarcastique. Comme je n'ai pas vu un lien vers une doc, j'espère que les noms sont "auto-explicatifs".

Quand je m'en suis occupé, j'avais juste assez de temps pour exploiter la fenêtre de temps où le gestionnaire NuGet fonctionnait.
Ma machine est un peu ... poétique, alors il faut en profiter pendant qu'elle est bien lunée.