Reprise du message précédent :

Oui tu fais des plan de maintenance via les jobs, backup full tous les jours et backup incremental à ton interval de temps qui correspond au rpo souhaité (ça peut être toutes les heures, demi heures etc).
Il vaut mieux sauvegarder sur un autre disque que celui du serveur, mais attention au réseau si tu passes par un nas, sauf si tu es en 10gb entre les deux ou si tu travailles directement avec des disques dans le serveur ou une baie San avec le réseau qui va bien.

Mais si les bases sont pas énormes ça va bien.
Pas oublier la replication ailleurs si tu veux un pra.

Ma référence c'est ça : https://ola.hallengren.com/
Backup, reorg/defrag des index etc. niquel

Top, merci bien

Pour une solution qui fait juste les .bak, SQL Server Agent ou batch (cmd) qui jouent les .sql dans le task scheduler.
Pour un truc qui fait tout je m'étais développé mon propre utilitaire qui génère le backup en appelant les bonnes commandes, le compresse et encrypte, et le balance sur le NAS + serveur cloud.  
Les scripts sur https://ola.hallengren.com/ peuvent aider mais c'est bien lourdingue et généraliste quand même, en pratique pas besoin d'un truc aussi riche je trouve.

A part ça, les gens qui font régulièrement du .Net Core et qui ont régulièrement utilisé Authorization/Authentication, vous auriez une idée là-dessus : https://stackoverflow.com/questions [...] core-3-mvc svp ?
J'en ai marre de distribuer des bounty pour recevoir des réponses qui ne font pas avancer
Merci

A vue de nez je dirais un souci dans la définition des policies. Perso j'utilise pas mal les AuthorizationHandler car j'ai rarement des policies simples. Ça va complexifier un peu ton code, mais au moins ça devrait te permettre de debugger ce qui se passe. Article détaillé : https://jakeydocs.readthedocs.io/en [...] icies.html

Ben même avec des rôles tous simples ça déconne aussi.
J'essaierai, ne serait-ce que pour voir si l'attribut Authorize est effectivement évalué par le code, ça fait quelques jours que je dois revoir ça de toute façon mais j'avais laissé le sujet en plan. Là c'est comme si l'attribut était transparent mais vu que j'utilise la définition "native" je ne sais même pas si on y rentre ou pas.
Je me disais qu'activer les logs MVC en mode qui cause beaucoup pouvait peut être aussi m'aiguiller.

Messieurs, j'ai un petit souci récurrent avec mes développements .NET / SQL Server, je pense que ça vient d'une mauvaise habitude ou d'un conflit de versions quelque part, mais ça devient assez handicapant...

Je ne peux plus faire de comparaisons de schémas entre ma base de données SQL Server et mon projet SQL dans ma solution.
Ca fonctionne sans problème au boulot, au quotidien (VS 2017 / serveur SQL Server 2014), mais pour mes devs à moi, peut importe d'où je bosse (VS 2019 / serveur SQL Server 2017), c'est mort, la comparaison fonctionne, mais l'update plante avec ce message dans la barre d'état :

Vous avez une idée d'où ça peut venir ?

Je ne vois même pas de quelle fonctionnalité de comparaison de schéma tu parles . Il y a ça en natif dans VS ou tu parles d'un plugin genre un truc redgate ?

A part ça, trouvaille du jour, je crois bien que j'ai trouvé un bug intéressant dans la dernière version de l'EF Core... Il m'aura bien fait suer celui-là.

J'ai une base avec des VARCHAR(X) utilisé en PK et FK. C'est moche mais c'est comme ça.

En base, la casse peut être différente sur la FK et la PK à lui associer, mais la relation marche quand même (pas de violation d'intégrité référentielle ou autre, la collation est en CI_AI donc probable que ça joue, en tout cas le truc s'en fout des majuscules).

J'utilise l'eager loading pour chopper les objets associés à ces relations lors des requêtes par des Include.
Il semble que l'EF Core lui ne s'en fout pas de la casse : si ma PK a le même nom (casse identique) que la FK, la propriété de navigation fonctionne bien, par contre si la casse est différente la propriété de navigation est à null
Demain je passerai un coup de SQL profiler pour voir les requêtes et je vérifierai sur un exemple simple si j'ai le temps, c'est bizarre quand même !

Ah en effet, je parle d'un outil natif intégré à VisualStudio quand on travaille sur des projets SQL (.sqlproj), et qui ressemble très fortement aux outils Redgate des années ~2010 :

J'ai absolument jamais utilisé cette fonctionnalité
Faudrait que je vois tout ce que les .sqlproj permettent dans les dernières versions, si ça se trouve il y a des choses bien utiles
Bon courage avec ton pb

Deux questions générales :
- Ton VS et ton SSMS/SQL Server (au cas où le truc aurait des dépendances bizarres) sont à jour ?
- Tu n'as pas des données utilisateurs (dossier caché ".vs" à côté du sln) corrompues ? Parfois quand VS part en vrille ça lui fait du bien d'essayer de supprimer entièrement ce répertoire et généralement à part quelques paramètres du workspace tu n'y perds pas grand chose.

Merci pour ta réponse

A propos de cette fonction.
Je m'en sers depuis quelques années (depuis que c'est intégré à VS en fait, même dans la Community)
En général, pour les petites modifications de structure (procédures stockées, ajout de champs "plats" ) je passe par le Projet SQL.
(pour les modifications plus lourdes (changement de types, créations de tables ou de relations...) je passe quand même par SSMS puis "j'aspire" les modifs dans le SQL Proj)
Le principal intérêt c'est de pouvoir générer mes scripts d'upgrade (structure et même données si nécessaire), les modifier si nécessaire et les jouer sur mes différents environnements de livraison.
J'ai donc un retour visuel sur ce qui va être altéré, dropé, ajouté, supprimé...
Mieux, comme c'est un projet dans la solution, le SQL est analysé et compilé à la compilation de la solution : tu as donc une vague idée de si ta proc a des chances de tourner en prod

Ensuite, je mets à jour mon EDMX pour que mon appli ait accès à ces modifications (je ne suis pas convaincu par la génération de la base de données directement par l'EDMX).

C'est un peu "so 2012" comme façon de bosser, et c'est même plus supporté dans les dernières versions du SDK (à ma connaissance, EF Core ne supporte plus l'entity data model), mais ça marche, et ça fait des livraisons assez propres je trouve.
La plupart du temps, je suis tout seul à bosser sur mes projets, je n'ai pas le luxe d'avoir un DBA ni un architecte à ma dispo, donc utiliser ces outils m'aident grandement dans l'organisation de mon travail

Pour le reste :
Je pense être à jour oui, je vais aller checker ça.
Je suis en VS2019 v16.4.5 et SSMS v18.4.
Les bases de données qui posent problème sont toutes sur la même instance, en SQL 2017 (14.0.2027.2)

Je vais regarder pour les données utilisateur corrompues, ça c'est bien possible

Ok. Je t'avoue que j'évite fortement les procédures stockées (même si je leur reconnais des avantages pour certains cas, notamment quand tu as des traitements ou des SELECT complexes et qu'un DBA veut avoir la main dessus).
A la limite pour les vues ça pourrait m'être utile de me mettre à bosser avec.
Pour le reste je me contente de versionner tous mes scripts SQL et de modifier les fichiers directement, ou d'en créer de nouveaux qui se chargent des modifications de façon incrémentale.

Concernant l'EF Core, oui il n'y a plus de concepteur graphique. Mais (heureusement) il reste possible de faire du Database First, moyennant quelques manips (un peu plus qu'un clic droit sur ton EDMX ).
Il faut suivre les quelques indications et contraintes citées ici et ça fait le job : https://stackoverflow.com/questions [...] 8#51347228
J'ai mis longtemps à abandonner l'EF6 et son modeleur mais au final je trouve l'EF Core bien pratique même pour des applis sérieuses où on ne veut pas que le code fasse n'importe quoi avec la bdd, pourvu qu'on ne fasse pas de Code First donc.

De toute façon faudra bien que je m'y mette au Core, j'ai 2~3 projets sur le grill qui attendent, dans cette techno
Ce sera des projets tout neufs, donc je pense pas qu'on partira DB First, au moins pour 1 d'entre eux.
 
Pour le reste c'est vrai que j'ai pas précisé une chose importante : dans tous les cas où j'ai utilisé ces fameux SQL Proj, j'était en contexte DB First, justement, sur des bases de données déjà éprouvées et peuplées, où une migration vers une nouvelle structure Code First m'aurait coûté cher en temps
 
Dans ce cas-là, je "subis" donc les procédures stockées, tout comme toi en effet
Je préfère aussi que toute la logique métier soit dans le code, mais bon tout le monde ne le voit pas toujours pareil (notamment quand il y a des DBA oui).

Il est possible de faire du code first, mais en générant toutes les classes/mapping via une DB.

Avec les data migrations c'est ça ?
J'ai essayé ça sur un projet il y a quelques années.
Entre les contraintes au niveau des nomenclatures et les commandes à taper à la main, on a très vite laissé tombé pour utiliser un bon vieil EDMX

J'en profite dans un tout autre domaine : c'est quoi vos précos en 2020 pour le log applicatif (erreurs ou pas que) en .NET ?
 
Log4Net c'est toujours dans le mouv' ?

Perso j'aime bien NLog.

 
Je crois qu'on s'en sert aussi dans quelques projets au boulot, je vais aller voir.
Merci bien
 
J'ai aussi vu Elmah il y a quelques années, qui expose carrément une interface web où on pouvait suivre les logs, erreurs, trafic etc...

Après faut voir ce que tu cherches aussi ; effectivement, pouvoir lire les logs et les interpréter avec des solutions types ELK c'est vraiment l'enjeu un peu partout.
NLog et log4net ce sont des libs juste pour le logging ; ELMAH a l'air de fonctionner un peu plus comme un framework mais j'en sais pas beaucoup plus, ne l'ayant jamais utilisé.

 
Pour ma part, c'est principalement du logging d'erreur ou d'états particuliers dont je veux être informé.
Je me demande même si un simple envoi de mail sur OnError() dans mon Global.asax ne suffirait pas

Si tu parles de logs applicatifs à l'ancienne dans des fichiers, log4net marche encore oui.
 
Les vraies méthodes dans le mouv' c'est les stacks de centralisation des logs style ELK / Graylog. Dans tous les cas mieux vaut éviter d'utiliser des libs spécifiques pour logger dans le code, en passant par LoggerFactory (mécanisme .NET de base) puis un ILoggerProvider pour l'implem (log4net / graylog / autre)

Top, merci à vous 2

Perso j'utilise NLog aussi. Très polyvalent et rapide à intégrer.
Log4Net pour moi c'est mort depuis des années, malgré quelques release ponctuelles.
 
Tip : au besoin il est possible de configurer NLog pour lui faire envoyer ses logs vers une target ELMAH, ou n'importe quoi d'autre : https://nlog-project.org/config/?tab=targets
Donc le fait de se tourner vers NLog côté intégration dans le code ne signifie pas se restreindre à lui.

NLog ou Serilog
je préfère ce dernier

Bonjour,

Petite question MVC Core (3.1) :
Vous savez comment on peut donner à manger au Model Binder une liste d'objets dans un form html, qui n'ont pas d'indexes séquentiels ?

J'ai un tableau de trucs (disons divers "input" html qui bindent un Model) construit dynamiquement par des drag drops, donc pas d'index.
Actuellement je me bats avec du JS pour essayer de bidouiller l'id et le name des objets à la volée pour avoir des index cohérents, mais ça donne un mic mac infâme et qui ne couvre pas tous les cas.
Je ne cherche pas à mapper juste une collection d'un type primitif (genre un string[]) où là on peut se passer d'index, mais bien une collection d'objets Model.
Si je pouvais juste drag/drop mes objets dans le tableau et laisser le model binder comprendre tout seul comment les mapper vers ma classe Model ça m'aiderait bien.

Merci

Les inputs sont bien ajoutées dans le <form/> ?
Si tel est le cas, tu peux pas checker à la mano (dans un premier temps, à défaut de mieux) ce qu'il y a dans le FormCollection que récupère ton ActionResult au POST ?

Quand j'avais des trucs un peu chiadés côté client (en tout cas un peu trop pour garder un beau ViewModel simple et compréhensible) je commençais toujours au plus bas, par chopper mes FormCollection.AllKeys, déjà pour m'assurer que ça postait bien côté serveur :

Exemple

EDIT : Ah, j'avais pas vu ton édit, tu cherches un truc un peu plus poussé (pour les types complexes j'imagine), là du coup, à part faire des aller-retours serveur (appels AJAX / posts intermédiaires / vues partielles...) pour enrichir ton modèle au fur et à mesure, je vois pas

Hello !
Le FormCollection c'est pas possible pour moi, mon Model global est très gros, c'est juste une petite où il y a ce système de drag drop.
J'ai besoin d'un POST à la fin, pas de petits posts en ajax au fur et à mesure, sinon il faut retravailler tout le truc.
J'ai fouillé un peu le web mais sans rien trouver, sauf avec des bricolages qui impliquent d'autres contraintes, en gros c'est comme si sans index on ne pouvait pas remplir une collection d'objets Model du client vers le serveur.
Merci

Pas sûr d'avoir compris. Perso à l'époque où j'utilisais encore du jquery, quand j'avais des form qui devenaient trop complexes genre avec une arborescence, je capturais le form.validate et je faisais un POST/PUT de l'objet json associé au modèle. Derrière le mapping côté ASP devenait trivial.
 
Pour moi ta limitation vient de HTML : form gère uniquement des clefs / valeurs.

J'ai exactement la même problématique au boulot où je dois peupler mon modèle "à la volée" aussi (objet "Famille" auquel j'ajoute des enfants au clic sur un bouton + côté client).
J'ai été (notamment) obligé de charcuter ma vue en remplaçant un joli @foreach() propre et typé, par un @for() qui simule les index qu'il te manque justement
Par contre de mon côté, je fais des "sous-submit" (merci le MVC qui permet de multiplier les <form/> )
Donc j'arrive à peupler la collection de mon modèle à renforts d'aller-retours serveurs (parce que l'archi de ma vue me le permet, en effet)

Je sais pas trop comment tu pourrais le faire nativement pour le coup
Peut être en ajoutant de la sauce framework JS (Angular ?) mais là aussi tu pars dans du chantier sale...

J'ai une demi journée pour finir cette partie, ça va être compliqué de tout réécrire pour utiliser Angular
Je me débrouille avec mon usine à gaz en JS qui recalcule les index dans les name et id des input à la volée (au fil des drag / drop) en utilisant des regex

 
L'avantage c'est que c'est une solution sur mesure, maintenable à court terme (disons, le temps que tu restes actif sur le projet quoi), et utilisant des composants simples
 
Perso, je suis pas pour utiliser des frameworks compliqués qu'on maîtrise pas, juste pour un besoin (allez, hormis Bootstrap et jQuery quoi, qui facilitent vraiment la vie...). Le temps que tu découvres la bibliothèque et que tu t'appropries le dev, la version est passée obsolète, ou ton projet est déjà arrivé au terme du temps imparti...

Mouais. J'utilise Vuejs depuis 4 ans :
- Encore moins de changements qui cassent la retro compatibilité que bootstrap
- J'ai commencé à sortir des composants dans mon appli en 3 jours, temps d'apprentissage "productif" 1 mois, et encore car je ne connaissais pas NPM
- Possibilité de l'utiliser sans NPM dans des projets legacy où tu as un besoin complexe
 
jquery c'est sympa pour du basique, mais ne pas avoir de MVVM dans une interface c'est quand même se mettre une balle dans le pied sur le long terme. A noter que je parle de vuejs, mais l'analyse est valable pour React, à ceci près que tu dois utiliser NPM. Angular par contre

Ca dépend des besoins !
 
Pour 99% des besoins que j'ai couverts en plus de 10 ans, je ta garantis qu'un projet SQL (pour l'infra BDD, et parce que j'avais pas d'équipe dédiée) + un projet DAL (entities, avec un EDMX tout auto généré) + une appli .NET MVC, ça suffit amplement et ça fonctionne très bien.
 
J'aurai pas l'audace d'avancer que tout le reste c'est de la branlette intellectuelle, mais KISS bordel !

 
Ok, sauf pour le DAL entities auto généré... je bascule sur une DAL à base de Dapper, bien moins problématique quand tu as des grosses évolutions de schéma, tu maitrise bien mieux ce que tu fais

Ben non justement, sauf à pisser uniquement du CRUD (où on arrive à égalité), c'est beaucoup plus complexe de faire une interface avec jquery que vue/react (mapping DOM / data notamment)

Exactement, tu te retrouves à écrire des tonnes de code js/jquery juste pour afficher et cacher des éléments  

Et avant que vuejs existe,  knockout faisait très bien le job, il y avait des solutions pré 2013/2014 pour s épargner le code répétitif de mapping DOM/data  

Je suis un peu largué dans votre échange. Au final le problème c'est d'envoyer au serveur un truc qu'il sera capable de mapper vers un Model en s'appuyant sur le Model Binder, donc la contrainte est essentiellement dans la manière dont le "POST" sera consommé, et la solution utilisée côté Front n'est pas si cruciale que ça (même si ça peut faciliter les choses de choisir la bonne) ?
 
En tout cas mon truc est assez infâme à comprendre quand on y rentre pour la première fois, mais ça marche nickel .

Avec un peu de chance, ça tombera dans les mains d'un petit nouveau en période d'essai d'ici 2~3 ans

Merci pour ce retour
Apprentissage en 1 mois, mais avais-tu des bases en JS ? Dev front ?

Pour faire mes bindings côté js, je crée des inputs hidden à la main que je rajoute au dom.
Côté controller j'ai une méthode qui reçoit le post avec une List<ChildModel>.