Reprise du message précédent :

 
Les temporal Tables, j'y pensais plus depuis que je suis obligé de me coltiner des vieux SQL 2012/2014    
 
C'est effectivement la meilleure solution native
 

 
Si tu voyais les tromblons que je me coltine avec des bases centrales mises à jour par SymmetricDS sur des centaines de postes client avec synchro bi-directionnelle...  

Je viens découvrir ça aussi. Sauf qu'évidemment moi là c'est juste pour du SQLite  

Je compatis tellement. Je refuse ce genre de mission sauf si l'objectif est de tout recommencer from scratch

  quand on te pose quelques dizaines de k€ en face, tu fais pas la fine bouche

Les gars, ça y est !
J'ai commencé à me mettre à RESTful / Micro Services / ASP .NET Core WepAPI / Swagger sur .NET 6, appelez-ça comme vous voulez
Il était temps

Pile technique projet :
- couche "front" : ASP .NET Core MVC (.NET 6.0) avec SwagggerUI
- couches "back" : .NET Core (.NET 6.0) avec EntityFrameworkCore

Question bête : est-ce qu'il est obligatoire de me limiter à une seule action dans mes contrôleurs MVC de l'appli front (qui reçoit les appels REST donc)
L'appli me jette des HTTP500 dès qu'il trouve plus d'un point d'accès, soit 2 actions dans un contrôleurs MVC.

Bien sûr, j'ai essayé avec des noms d'actions différents, des types de retours différents, des sensibilisations HTTP (POST/GET/PUT...) différents...

J'ai l'impression que ce pattern de projets Visual Studio que j'ai utilisé ne configure pas correctement la route MVC

C'est bien, dans 5 ans tu passeras à GraphQL  

C'est tout à fait le train de retard que je suis

Tu peux mettre une infinité d'actions dans un contrôleur. Tu dois avoir un autre souci.

Peut être un conflit dans les signatures de méthodes si les actions sont sur la même route avec des param incompatibles pour déterminer l'input ?

Ex :
[Route("/" )]
[GET] A(string, int)
[GET] B(string, string)

Merci pour vos réponses.

Effectivement sur mes applications ASP .NET MVC j'ai toujours pu gère mes actions comme ça mais là j'ai l'impression que le scaffolding du template de projet "Application Web Api RESTful" de VS2022 ne configure la route MVC justement.

A titre d'exemple, mes webmethods exposées, visibles dans SwaggerUI ont toutes des URL du genre "domaine/Contoller" les noms des actions ne sont jamais utilisées, donc forcément je comprends aisément que dans cette configuration soit ça accepte uniquement "Index" soit ça prend l'unique action autorisée par contrôleur

Je vais regarder ça de plus près et vous tenir au courant.

Pour de l'API REST, il faut toujours définir tes routes. On n'utilise pas le nom des controllers/méthodes pour construire les routes comme on peut le faire en MVC

[Post("/user" )]
public async User CreateUser(string name)
{ return default; }

Ou débrouille toi pour n'avoir qu'une seule action par verbe dans ton controler, avec un controler = une ressource REST. Comme ça tu défini juste la route au niveau du controler

Tu peux toujours définir tes routes avec controller/action via le Program.cs, mais c'est bizarre en effet pour du rest.

Dans tous les cas tu peux annoter tes controllers avec [Route("api/[controller]" )] pour avoir un nom racine (ce qui est pratique pour le coup), puis annoter tes actions en relatif à ce controller, style [Get("data/{id})"]

Bonjour, je n'arrive pas à quitter proprement un programme Windows rien qu'avec ce petit bout de code    :  

Quoique je fasse un processus reste active après avoir quitter le programme
 
Evidemment si j'enlève "connect.Open()" ça quitte proprement
 
Note : j'arrive à lancer des requêtes avec la même initialisation de la connexion

Commence par encapsuler ton 'connect' dans un `using` puisqu'il est IDisposable et essaye à nouveau

Vérifie qu'aucune exception n'est levée

Je l'ai fait pour la forme mais ça n'a aucune raison d'être différent qu'un "connect.Dispose()" direct... et ça n'en a pas eu

Toujours pareil après l'encapsulation dans un try-catch
 
 
Le pire c'est qu'après ouverture de la connexion, le programme ne consomme rien (heureusement) mais dès que je le quitte le processus restant se met à consommer 12% d'un i7-12700 !!?

Tu as testé avec un autre provider oledb ?
On dirait que le provider pour les bases de données de web?dev est daubé.

12%, on dirait un single proc d'un octocore qui tourne à fond en essayant de faire quelque chose lors du dispose dans le provider, genre libérer les ressources mais que ça repop en permanence ? Ou un bug à la con qui libère pas le thread.

C'est quelle méthode qui bloque ? Tu as essayé avec une autre base, située ailleurs ? Possible qu'il y ait un firewall qui bloque la séquence de fin.

Un pare-feu qui bloque la séquence de fin ?  

Ça me paraît très peu probable, si la connexion sur le port d'écoute TCP fonctionne à l'ouverture aucune raison que ça ne passe pas à la fermeture.

Le releaseopbjectpool après le dispose de connection me gêne un peu perso...
 
j'aurais plus tendance à faire ça :
 

 
ce qui est cohérent avec la doc :
 

 
https://docs.microsoft.com/fr-fr/do [...] at-ext-6.0
 
Ce qui est cohérent car le dispose pète totalement l'état de ta connection, l'objectpool ne connait pas un état stable de ta connection.

C'est pourtant possible, c'est Sioux un FW surtout ceux qui font de l'analyse protocolaire

ce qui est cohérent avec la doc :
 

 
Le 'ReleaseObjectPool' ne se faisant pas sur l'objet 'connect', je ne pense pas que ce soit un soucis de le faire après que le 'Dispose' ai été appelé (implicite ou explicite). Il faudrait jeter un oeil à l'intérieur avec ILSpy.
Par contre il faut bien que le 'Close' ai été appelé. Celui-ci est automatiquement appelé en fin de 'using', il n'est pas nécessaire de l'appeler explicitement.
 

 
 
On peut aussi log l'état de la connection avant et après l'appel explicite au close via 'connect.State'
Avec certain drivers, il faut faire appel à 'ResetState' pour avoir un status cohérent

Depuis que j'ai eu un firewall qui me bloquait SQL en 1433 sur mon appli ASP.net core mais pas le telnet ni SQL management studio, ça reste dans mes hypothèses.

Certes m'enfin ça m'a plutôt l'air d'être l'opération de la dernière chance à ce niveau.

Là c'est pas pareil car t'es au niveau applicatif, et s'il est autorisé à ouvrir une connexion, pas de raison que ça chie à la fermeture.

Après Je@nb a raison, il y a des FW qui font l'analyse de trame/requête, mais comme dit au dessus, ça me paraît être la toute dernière hypothèse à écarter tellement que c'est peu probable.

Mais Nan c'est juste une base de données locale Windev avec des fichiers .FIC  
 
Et je n'ai pas d'autres trucs "OLE" a tester
 

Ca ne change rien
 

Ca non plus
 
Bon j'imagine qu'il doit y avoir un souci avec la passerelle de Windev - surement une petite différence de fonctionnement sous Windows 10 ou un truc comme ça.
 
Bon alors je vais devoir regarder comment détruire des processus à la dure
 

Depuis peu, j'ai une nouvelle règle de l’analyse de code en .NET6 : JSON002 : Chaîne JSON probable détecté.
Je ne trouve pas de documentation ou d’explication la concernant, exemple dans un test unitaire :

La correction proposée :

Je comprend pas d'où ça sort ou l'utilité  

te faire de la validation syntaxique json dans le code c# ?

Ah oui effectivement c'est ça, merci Et JSON001 c'est quand le contenu est mal formé !

C'est bien ça : une nouvelle fonctionnalité (j'avais vu passer ça il y a quelques mois, mais on doit pouvoir retrouver un article facilement) pour assister à la saisie du json lorsque tu en as au milieu de ton code C# et faciliter les corrections.
 
J'ai aussi la même chose pour les regex depuis des années avec Resharper mais je ne sais pas si VS aussi les détecte ou si c'est du pur R#, et j'ai la flemme de le désactiver pour savoir
 
edit :

Hello messieurs,
 
Je bosse actuellement sur une application console, écrite en C# (.NET 6.0) et qui se connecte à une base de données existante (DB First) avec EntityFrameworkCore.
 
C'est une application de monitoring / logging et c'est surtout la première appli console en Core que j'écris, et ils ont tout pété les principes de base
Le fichier Program.cs n'a plus la même tronche, par exemple, et ne ressemble plus ni au Program.cs d'antan (celui avec le void Main() où on foutait tout en vrac) ni au Program.cs moderne (celui qui contient les services et les builds du programme en Core).
 
Pour la plupart de mes besoins, j'ai retrouvé mes petits et je me suis débrouillé.
Mais il reste 2 choses que je n'arrive pas à implémenter proprement. Pouvez-vous me donner votre avis svp ?
 
1- Lors du scaffolding de la base de données SQL Server (pour MAJ mes entities / dbcontext par exemple), je n'ai pas trouvé comment utiliser une chaine de connexion nommée, comme je le fais en ASP .NET Core ou WPF Core. Malgré la config appropriée dans le builder, le scaffolding ne trouve pas chaine nommée dans ma configuration d'application Console. J'ai essayé de la mettre dans app.config et dans appSettings.json, rien n'y fait.
 
2- Probablement liée à au point 1-, je n'ai pas réussi à implémenter la façon habituelle que j'utilise (settings dans le appSettings.json + classe AppSettings.cs + injection IOptions dans les constructeurs). Ici, aucune méthode dont j'ai l'habitude ne passe parce que le Program.cs semble spécifique.
 
Pour ces 2 points, j'ai des solutions alternatives :
1- explicitation de la chaine de connexion au moment du scaffold et dans le dbcontext -> provoque un warning et m'empêche de dynamiser en fonction de mon environnement.
2- utilisation à l'ancienne d'un app.config + ConfigurationManager.AppSettings.Get("maClé" ) -> archaïque et m'impose des tas de contrôles de types...
 
Merci à vous pour vos lumières !

Tu as bien installé les packages nuget Microsoft.Extensions.Configuration et Microsoft.Extensions.Configuration.Json, et éventuellement  Microsoft.Extensions.Configuration.Binder pour mapper à des objets ? Ça te donnera un comportement similaire à ASP.net core.

Si tu veux de la DI il te faudra aussi ajouter des packages associés.

1) Pour ça personnellement j'utilise l'extension EF Core Power tools maintenant. C'est plus souple et pratique que les lignes de commande.
Si tu veux qd même utiliser le scaffolding là tu trouveras quelques trucs à vérifier si pas déjà fait : https://stackoverflow.com/questions [...] 8#51347228

Et pour le code .Net 6.0 "soit disant" plus simple ("top-level statements" ), ça a été beaucoup débattu (et critiqué) sur les forums Microsoft.

On peut rétablir une partie des anciens comportements en désactivant les "implicit usings" dans le csproj, et rien ne t'empêche de remettre une classe d'entrée et une méthode Main explicites.
Le seul truc bien (selon moi) dans leurs "simplifications" c'est la possibilité de spécifier le namespace en début de fichier sans devoir mettre le code contenu entre accolades : ça évite un niveau d'indentation.
Mais le reste je trouve ça moche et confus si t'as besoin de faire un truc un poil plus sérieux qu'un Hello World.

edit : regarde les votes sur les 3 premiers posts de cet échange pour voir à quel point cette pseudo-évolution a été populaire : https://github.com/dotnet/docs/issues/27420

On en avait déjà parlé y a 2 pages
https://forum.hardware.fr/hfr/Progr [...] m#t2407281

Exact

Merci pour vos réponses
 
J'ai trituré un peu le truc, et après quelques heures, je suis toujours bloqué... Y a des tonnes de documentations sur le sujet (pourtant récent) ce qui prouve bien que personne n'y comprend rien, ça me rassure...
Enfin la plupart concerne .NET 6 avec ASP .NET Core, et la façon d'implémenter une WebApplication... pas une application console donc.
 
Déjà, j'ai réussi à faire (re)fonctionner le scaffolding bdd, en ajoutant un Generic Host avec un builder de configuration à mon appli. J'ai ajouté manuelle mes fichiers appsettings.json / appsettings.development.json et avec une habile et dégueulasse directive if DEBUG, j'arrive à ça (puisque la détection par environnement ne fonctionne pas non plus) :
 
 
Mon Program.cs ressemble donc désormais à ça :

 
et ma classe de DbContext (auto générée par le scaffolding), ressemble à ça :  

 
J'ai donc déporté mon code dans une classe "DiBerieBotMain" qui implémente IHostedService et IHostApplicationLifetime :

 

 
Du coup tout monde code originel se retrouve threadé-mais-en-fait-non dans le StartAsync (mais-en-fait-non) :

 
Et bien évidemment, au premier appel à ma base de données :
->
 
Bref, tout ça pour ça...
Je suis content ceci-dit, je peux maintenant envoyer mon code sur Git vu que la classe de contexte n'affiche pas honteusement ma chaine de connexion explicite ...
 
Prochaine étape : je vais jeter un oeil à EF Core Power Tools, merci à vous.
On sait jamais, peut être que lui me fournira un exemple concret et fonctionnel de bout de code que je pourrai exploiter
 
EDIT : Ce type a eu, il y a 13h exactement le même souci : https://stackoverflow.com/questions [...] ng-for-dbc
J'ai essayé la solution qui lui est proposée :

 
Même problème ici : https://stackoverflow.com/questions [...] as-not-fou
 
Et ça fonctionne pour le scaffolding (donc plus besoin d'expliciter ma chaine de connexion), MAIS ça plante toujours lors de ma première requête EFCore, même sans passer par le service hosté :

 
EDIT2 : Ok, c'est bon je l'ai
En fait, le problème venait bien de moi et de ma façon archaïque de penser, sans injection de dépendance...
Au final, le seul fait de configurer SQL Server dans le démarrage de l'application suffit à exporter la classe de contexte :  

 
et donc, c'est aussi simple qu'en contexte ASP .NET Core (avec un host WebApplication) de le "consommer" (c'est comme ça qu'on dit pour une injection de dep ?), ici dans le constructeur du HostedService :

 
et voilà !
Le reste de l'appli propage simplement cette instance dont la chaine de connexion est bien tirée de la config de l'application de démarrage
 
Pardon pour le pavé du coup, mais je laisse, au cas où ça puisse aider d'autres personnes

Pas de pb, ça peut effectivement servir
 
A l'occasion je te recommande quand même de tester EF Core Power Tools, c'est nettement plus pratique et puissant que le scaffolding "natif" en ligne de commande.

Oui en effet du coup j'ai pas suivi cette piste là, mais je vais tenter, je suis pas fan de la commande à taper dans le gestionnaire de packages non plus  

TotalRecall, est-ce que tu veux bien être mon papa ?
 
J'ai pété un câble il y a quelques jours... je pensais m'être sorti de mes histoires de configuration .NET Core Console App + EF Core + DB First... mais en fait non, au premier scaffolding après avoir ajouté une table à ma BDD --> crash avec le même message d'erreur.
 
Du coup j'ai donné sa chance à EF Core Power Tools, et je sais pas à quoi il carbure, mais tout est passé et tout fonctionne !
L'outil m'a généré une belle classe de DbContext avec une chaine de connexion nommée (donc exactement ce que je voulais, plus sécure) et en prime je retrouve le formalisme [DataAnnotation] dans les entities comme à l'époque d'EF / EDMX.
 
J'ai trituré un peu le truc, et ça a l'air vraiment robuste !
Ca prend même en charge EF Core 7 Preview (je ne savais même pas qu'il y avait déjà une preview d'EF Core 7 !) et ça devrait en théorie permettre de générer la base de données (via les Migrations).
 
Bon, pour cette dernière partie, je préfère me reposer sur les bases franchement plus solides d'un bon projet SQL (.sqlproj) pour générer la structure + scripts manuels pour les données.
 
Bref, cerise sur le gâteau, j'ai pu simplifier (et sécuriser du coup) la configuration et le démarrage de mon projet de démarrage, puisque désormais c'est EF Core Power Tools qui génèrera ma couche DAL, et non plus le db-scaffolding en CLI
 
Un grand merci du coup, là je t'en dois une
(et j'ai des témoins, j'ai fait ça en live sur Twitch )

Messieurs,
 
Vous avez un moyen en C# d'obtenir les informations du media en cours de lecture sous Windows 10/11 ?
 

 
https://github.com/DubyaDude/WindowsMediaController ?