Reprise du message précédent :
Semi HS, mais vous avez tant que ça besoin de l'accès admin ? Perso une fois ma stack installée, je n'en ai plus besoin que pour les Màj logicielles. Testé chez un client, je devais demander un accès toutes les 2/3 semaines.

Bon après ma stack est suffisamment grosse pour emmerder les plus pénibles (node, DotNet avec divers IDE, docker), et j'installe autant que possible sur mon profil, ou utilise docker pour les CLI / env exotiques

De moins en moins besoin aujourd'hui, sauf quand je n'ai d'autres choix que de travailler avec WSL. Docker j'ai très souvent des soucis et besoin des accès admin
 
Mais VS, quand il n'est pas lancé en admin, c'est aussi des soucis à répétition, des crash random, des comportements... incompréhensibles, surtout lorsque l'on travaille avec plusieurs instances pour plusieurs solutions
 
Je suis régulièrement amené à travailler en environnement très sécurisé chez des clients sensibles. Finalement la meilleurs pratique est simplement de ne pas nous inclure dans le réseau. Nos PC ne sont plus qu'un simple terminal lambda isolé avec un accès au net. Quand on travaille sur des applications déployée intégralement Azure ou AWS, on a aucun intérêt à avoir une machine enregistré sur le domaine.

De mon côté, chez mon client actuel en remote vu qu'ils hébergent tout eux-même, t'es plutôt obligé d'être en VPN toute la journée, donc avec un pied dans le réseau.

Et j'ai besoin des accès admin quasi tout le temps :
- VS dont certaines fonctions/plugins déconnent si pas admin (genre EF Core Power Tools),
- MAJ de tous les outils du quotidien (VS, Notepad++, Kreya, Winmerge, Resharper...), à eux tous cumulés j'en suis à plusieurs installs par semaine
- Les outils un peu "système" comme LockHunter qui ont besoin de privilèges élevés et qui servent assez souvent

Partant du fait qu'on installe des trucs "justifiés" et que les admins ne sont absolument pas disponibles, l'idée d'être infantilisé ou de devoir poireauter chaque fois que je dois installer qqch me paraitrait inacceptable.

WSL / Docker c'est pas trop mon quotidien (et c'est très bien comme ça )

Ah oui c'est sûr quand tu utilises lockhunter / wireshark / autre débug misère c'est tout de suite plus utile

Les mises à jour on était arrivé à mettre en place des politiques à base de certificats d'éditeurs de confiance, donc pas de souci de ce côté, ça passait tout seul.

Bizarre les problèmes avec VS par contre, pas de souci de mon côté, et pourtant j'ai toujours 3/4 solutions ouvertes. Mais pas trop d'extensions j'avoue, à part les classiques sonar / MS powertools (et pas d'EF core powertools notamment). Mais je ne fais pas de desktop, j'avais entendu que c'était plus galère pour eux niveau stabilité.

Docker déconne plus, je dois rebooter mon poste une fois par semaine pour le remettre d'aplomb. Mais je bourrine pas mal aussi de ce côté (habituellement 15 / 20 containers)

Y a pas longtemps une collègue a été emmerdé avec un développement maison. On fait de l'acquisition d'image via scanner, mais ça ne marchait plus.
Obligé de passer VS en admin pour que ça fonctionne.
J'ai pas suivi la fin de l'histoire mais on en a chier pour découvrir ça déjà.

Par contre qu'est ce que c'est instable avec wpf . Obligé de fermer/relancerr VS après des modifs sinon t'a des erreurs qui persistent , qu'elle galère

Avec une solution type API et un très grand nombre de tests unitaires, les tests finissent régulièrement pas ne plus se lancer si pas en admin. Quel que soit le moteur de test.
En cas d'utilisation de NCrunch, c'est même assez courant.
Avec des projets SpecFlow j'ai aussi eu des soucis très aléatoire qui m'ont fait perdre un temps fou, alors qu'une fois admin, plus aucun problème

C'est quoi très grand ? J'ai eu plusieurs projets entre 5000/10000 tests sur plusieurs projets sans souci avec xunit, avec pourtant du testcontainers / intégration.

L'intégration de scanners, pour bosser dans le domaine, je comprends plus que ça merdoie par contre (accès à des ressources natives / drivers).

Un REX sur specflow sinon ? Je m'étais tâté à le mettre sur des projets, je me demandais si au quotidien ça n'alourdissait pas le flow d'écriture des tests

Entre 3 et 5k tests. Le symptôme, c'est essentiellement des tests qui ne se lancent plus (no result) jusqu'au redémarrage de VS.
 

J'ai honnêtement l'impression de perdre un max de temps avec specflow. La seule vrai utilité c'est lorsque tu es sur du test d’intégration et que tu as besoin de construire un grand nombre de dataset pour couvrir de nombreux cas de tests d'un même endpoint. Dans ce cas, un product owner doit normalement être capable de prendre en charge une partie du taf avant même d'attaquer les développements.

OK merci. Tant que je n'ai pas d'équipe QA qui fait du gherkin en parallèle je vais continuer d'éviter du coup

Après, si t'en a jamais fait, ça vaut le coup d'essayer au moins pour découvrir le fonctionnement. Je pense que suivant la situation ça peut être pas mal

Hello,  
 
Des gens ici qui ont fait du MAUI déployé sur Android ?  
J'ai bien envie de m'y essayer pour une toute petite appli à usage perso (avant d'inonder le monde avec et devenir le nouveau Bill Gates naturellement ).
J'ai pas encore pu déployer sur mon Android (il ne suffit pas de copier l'APK généré et l'installer en autorisant les sources inconnues, apparemment faut faire un bricolage manuel pour signer l'app quoi qu'il arrive).
Mais côté VS, ça semble avoir bien maturé avec le temps, l'émulateur Android tourne presque du premier coup, et ça a l'air agréable à développer, le hot reload est bien pratique.  
Par contre ça suce du CPU et de la RAM à un point impressionnant même avec juste le hello world.
 
Je suis curieux de voir ce que ça donnera sur Android, genre s'il faut 15s pour que l'app s'ouvre vu son usage ça ne va pas le faire. Avant de développer le truc je vais tester de déployer un truc minimaliste.

Excellente question ça, ça m'intéresse aussi

Je m'auto-réponds avec un petit CR .

J'ai pu y passer un peu de temps et je suis arrivé à mon objectif (j'ai une TODO list de 2 pages mais l'app fonctionne bien pour un MVP ).

Je confirme dans l'ensemble mes remarques plus haut :

Côté Build :
La chaîne de compilation n'est pas encore très mature, ça bug facilement (genre j'ai une erreur sur un EXE "makepri.exe" introuvable, en cible... Windows, même avec tous les SDK qui vont bien et un VS à jour. J'ai pas cherché trop longtemps vu que ce qui m'intéresse c'est le côté Android). Et je me suis débattu avec quelques autres anomalies exotiques.

Mais une fois que tout est bricolé à l'arrache en testant des trucs au pif configuré de manière optimale, avec l'émulateur ça tourne bien. Pour lui il faut également faire un peu de tuning (activer la virtualisation dans le BIOS, etc), et compiler en Debug (peu importe qu'on lance ou non le débugueur) pour développer, ça permet aussi d'avoir le hot reload.
Pour générer un APK signé, il faut passer par un outil java en CLI (keytool -genkey ....) pour générer un keystore, et bricoler des trucs dans le csproj.
Une fois que c'est réussi, ça s'installe facile sur l'Android, donc pas trop galéré là dessus.

Côté dev :
Toujours pas de designer. Par contre avec le débugueur et le hot reload d'actifs on a un aperçu en temps réel des modifs faites sur le XAML
Le profil Release fonctionne aussi à l'exécution, par contre c'est BEAUCOUP plus long à compiler, on parle de plusieurs minutes, apparemment ça optimise énormément.
On peut ne s'en servir que pour le build final (signé) MAIS j'ai remarqué un truc : là où un profil "Debug" fonctionne, un build en Release peut crasher avec exactement le même projet. A priori toutes les mécaniques d'optimisation rendent le Release plus sensible à des petites erreurs dans le XAML (ou autre chose ?) qui ne déclenche aucun avertissement dans VS.
J'ai eu le coup, j'ai mis un peu de temps à comprendre, donc plutôt que bosser 1 journée entière sur le truc, changer plein de choses et me rendre compte à la fin que parmi tout ce qui a bougé il y a une ligne cachée quelque part qui fait crasher en Release, je teste ponctuellement .
Sachant que ce cas de figure en Release plante aussi bien dans l'emulateur que sur un vrai Android, ça vaut le coup de tester de temps en temps de lancer en Release pour voir si on n'a rien cassé .
Les composants d'UI sont minimalistes (en très gros : plein de trucs pour gérer le layout, ensuite des textbox, des labels, des boutons et ça s'arrête à peu près là). Il n'y a pas l'air d'avoir beaucoup de composants gratuits évolués (on est loin de ce que propose Blazor et les libs Web en général par exemple)
L'apprentissage rapide si on a déjà fait du XAML.
Globalement c'est très gourmand en ressources, pourtant j'ai CPU avec 24 coeurs logiques et 32Go de RAM et mon appli est petite.

Côté exécution sur l'Android final :
Un build en Release d'un truc comme le Helloworld prend environ 10Mo il me semble, le même en version signée prend 30Mo (ouais ça fait gros pour une signature, il doit se passer d'autres trucs )

J'ai été content de voir que sur mon "vieux" Xiaomi 11 d'il y a un peu plus de 2 ans, ça tourne très bien malgré l'abstraction .Net/MAUI.
Mon appli prend entre 1s et 2s seulement à démarrer (app basique sans dépendances pour le moment), ça me parait totalement raisonnable. Par contre graphiquement elle ne fait rien de dément donc j'ai pas de recul sur ça.

En tout cas maintenant tous les jours depuis 10j elle fait le job auquel je la destinais, donc je suis satisfait .

Merci pour ce retour

De rien, je l'ai fait justement parce que t'as répondu donc y avait au moins un intéressé potentiel
Si tu te lances dedans ou si tu te poses des questions n'hésite pas, ça fera vivre le topic

Je vais m'y intéresser un de ces jours, une envie me démange d'écrire une app client HFR en C# mais bon, c'est le courage qui manque pour le moment
 
Sinon, question Visual Studio : il y a moyen de faire afficher à Visual Studio le nombre de référence dans une classe à une propriété privée
 
Code Lens l'affiche pour les props publiques, c'est super pratiques, mais parfois j'ai affaire des des classes monolithiques totalement obscures "à l'ancienne", et j'aimerai bien pouvoir naviguer dedans en suivant les traces des constantes / props privées sans forcément utiliser la recherche ...

Hello les copains. J'ai passé l'après midi a essayé de solutionner un soucis, et ca me pose une question.
 
J'ai une solution avec un projet "core" qui contient le code metier, un projet console pour le debug et avoir les logs, un projet service qui est déployé en prod.
On a fait des grosses modifs sur une DLL maison (gestion de message broker avec rabbit Mq) embarqué dans le "core", dont on avait ajouté le projet a la solution pour se faciliter les debugs.  
Une fois tout OK, on a compilé notre DLL, déposé sur un repo Nuget, et remis les références dans la solution via Nuget. Tout compile on est content.
On déploie le service, ca démarre pas. En débug dans le projet console, ca démarre pas non plus.
 
Après avoir fait appel a un collègue et y avoir passé un bout de temps, on a viré des lignes dans le fichier de config de l'appli, notamment tous les dependentAssembly. Ca à tourné, on a donc cherché celui qui nous faisait chier et il s'agit de celui ci.

 
 
Les questions :  
A quoi ca sert ? Si ca tourne sans je me demande si je vais pas tout simplement tous les virer ?
Des versions différente de cette assembly dans notre DLL message broker et dans notre projet "core" peut il causer l'erreur ?
Je viens de regarder, notre projet core a une référence a la version 4.0.5, notre Dll une version 4.0.4.1
 

Euh c'est du legacy avec du pas-Core dedans ?
Parce qu'un projet Core avec un fichier de config XML et ces saletés de bindingredirect c'est un peu chercher à se compliquer la vie .

.net 4.6.1
On est en train de faire des montées de versions vers .net 6 puis potentiellement 8 mais on a du taf.
Ça sert a quoi ces bindingredirect ?
Mon collègue me disait qu'il essaye de les virer quand il déploye.

En super résumé, à forcer l'utilisation d'une version spécifique d'une librairie quand il y a plusieurs possibilités.
C'est mis à jour auto-magiquement lorsque tu fais des MAJ par nuget par exemple.

Ca devient bordélique justement quand tu déploies parce que c'est perdu au fond du fichier de configuration : si ça a bougé en dev mais qu'on ne reporte pas la modif en prod, ça fait tout exposer (erreur d'assembly binding) parce que les versions ne correspondent plus.

Parfois il n'y a pas de "conflit de version" possible, donc on peut supprimer complètement les lignes (qui risquent de revenir par nuget).
D'autres fois au contraire on doit impérativement les garder pour aider le runtime à faire les binding.

En .Net Core t'as à peu près la même chose dans les fichiers .runtimeconfig.json et .deps.json, sauf que là c'est des fichiers qui ne contiennent QUE ça donc c'est bcp plus simple : tu les déploies avec l'appli sans t'inquiéter de rien, contrairement à un app.config ou web.config qui contient 150 paramètres utilisateur et connectionstrings à ne surtout pas déployer.

Pour les cas vraiment tricky, y a des (vieux) outils pour détecter ces erreurs au démarrage et voir qu'est ce qui n'a pas été trouvé, il me semble que c'est fuslogvw.exe (mais j'ai pas ouvert ça depuis 10 ans moi, je te raconte tout ça de mémoire, donc à vérifier).

C'est typiquement le genre de choses que MS a bien amélioré depuis le FW .Net : le format de projet SDK, les fichiers de conf en JSON, et récemment les fichiers .slnx, etc etc.

edit : et condoléances pour ta version antique du FW

Je vois.
Je pensais que ce binding permettait de dire , si tu a les versions de X a y, tu utilises la version max indiquée.
Va falloir qu'on fasse gaffe au déploiement sur les différents environnements oui, ça me fais suer d'avance.
Ou alors qu'on vérifie les versions de chaque dll dans chaque projets.

Merci pour les éclaircissements.

Généralement c'est plus dans un esprit "si le projet a l'air fait pour une vieille version mais qu'en t'en as une plus récente sous la main, essaye plutôt de la prendre elle".
C'est parfois utile si t'as un vieux projet alors qu'autour de lui le monde a évolué, ça lui permet de continuer à fonctionner sans avoir à le recompiler, etc.
Ca part d'une bonne intention mais au final c'est un truc assez pénible quand il faut les maintenir comme ça semble être là votre problème.

Ce qui est fou c'est que j'avais pas une erreur de build ou de runtime.
C'est mon rabbitmq.client qui explosait a la création de la connexion.
Mais ça fonctionnait dans un projet a part, donc je doutais pas trop de mon code. Par contre j'y ai passé l'après midi.

rabbitmq.client doit lui même avoir un troupeau de dépendances dont certaines qui se font choper par les redirects donc ça gueule quand il monte l'assembly et ce qui vient avec et qu'il commence à taper dedans.
Normalement t'as quand même une exception qui met un peu sur la piste pour comprendre que c'est une histoire de binding incohérent.

Autant avec newtonsoft.json j'ai eu une erreur ou il n'arrive pas a charger l'assembly avec le publickeytoken XXXX, mais la, non, il va jusqu'à l'ouverture de la connexion et te jettes un erreur d'accès réseau (timeout, ou pas d'accès a l'IP demandée).
Bref, ce matin j'ai remis d'aplomb les DLL système un peu partout, en tout cas, la même version dans tous les projets.