Reprise du message précédent :
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>.
 

Full stack à dominante back, voire dev système. Mais j'aime bien JS je dois avouer, donc j'avais les bonnes bases : manipulation dom + utilisation des prototypes. Du coup comme j'ai dit le plus long a été l'apprentissage/mise en place de l'écosystème npm, notamment webpack qui est assez touffu. Si tu as déjà fait du JS et que l'archi du projet est déjà posée, ça prendra nettement moins qu'un mois.

Après il est possible d'importer vuejs directement comme fichier JS dans ton fichier HTML, pas besoin de toute la tuyauterie webpack. Sur un projet legacy généralement t'as pas trop le choix

Yep, j'ai fait les deux d'ailleurs. Pas à recommander : tu perds du coup les dépendances npm ( ), et la transpilation. Mais bien pratique pour des interfaces complexes : dans mon cas un dashboard et un arbre avec drag&drop. Le reste du projet marchant nickel avec cshtml (parties crud), mais pas eu le courage de migrer

Tiens, je pose là une petite dépendance que j'ai utilisé récemment.
Quand on bosse avec des Enums et dessus des attributs (Description, Name...) ou des modificateurs comme Flags, on se retrouve vite à avoir une tripotée de méthodes d'extensions et/ou de Helpers pour faire ce qu'on veut. Genre les flags avec juste les méthodes natives et opérateurs binaires c'est une plaie à manipuler et relire.
Ben on trouve tout ça, et bien plus encore, sous une forme testée et optimise dans cette sympathique librairie : https://github.com/TylerBrinkley/Enums.NET

Et vu la racine de son github, c'est pas son seul projet dans le genre.

Bonjour,

j'ai un peu de temps ces dernier temps  
Je me suis dis pourquoi ne pas refaire un peu de dev comme à l'époque.
J'ai donc voulu télécharger VS Community 2019.
Je privilégie le téléchargement pour une installation offline
J'ai donc suivi d'abord ceci: https://docs.microsoft.com/fr-fr/vi [...] ew=vs-2019
Puis cela car cela correspond plus à mon besoin: https://docs.microsoft.com/fr-fr/vi [...] ocal-cache
Le téléchargement et l'installation de l'utilitaire se passe très bien.
Mais les commande ne fonctionnent pas. (mode utilisateur ou admin)
J'ai un message d'erreur de ce type (pas la formulation exacte car je ne suis pas sur le bon PC):

Des infos là dessus svp ?
Merci

Visiblement vs_community ne se trouve dans aucun des chemins listés dans ta variable PATH. Donc soit tu ajoutes le dossier contenant vs_community dans ton PATH, soit tu changes le dossier courant de ton cmd pour celui contenant vs_community.exe.

(Et j'en profite pour poser mon petit drap )

Ah oui, effectivement.
Tout fonctionne.
Parfait, merci

salut  
 
certain d'entre vous utilisent t'ils monodevelop sous Linux ??  
 
je viens de l'installer sur une nouvelle installation et pas moyen de lancer un simple :  
 
using System;
 
namespace exo5
{
    class MainClass
    {
        public static void Main(string[] args)
        {
            Console.WriteLine("Hello World!" );
        }
    }
}
 
sous la gui monodevelop , en fait il me sort :  
the name "Console" does not exist in current context.  
 
Mais en terminal je lance un msc Program.cs et il me le compile bien et je peux lancer le .exe correspondant.  
 
J'aimerais vraiment re-passer sous linux, j'ai débuté la programmation en fin d"année 2019 et j'ai plutot bien avancé avec V community.  
Mais mon OS de coeur reste tout de même Linux ( Debian\ Gentoo )
 
Si vous aviez une idée, merci bcp  

Désolé de ne pas vraiment répondre à la question (jamais utilisé mono), mais tu ne peux pas passer à dotnet core ?

Dans le cas contraire je suis curieux de savoir ce qui bloque, à ma connaissance mono n'a pas de fonction que dotnet core n'aurait

que veux tu dire par passer par Dotnet core ?
rester sur VS community (Windows )?

Non, utiliser le sdk dotnet core (multi plateforme) au lieu de mono.

L'IDE n'a pas d'importance après : sous linux vs code marchera bien, mais tu peux prendre  vi si ça t'amuse. Tu peux ensuite construire tes applis via CLI, typiquement "dotnet new"  pour initialiser un nouveau projet ou "dotnet build" pour le construire.

+1

VS Code + DotNet Core me semble le moyen le plus simple et le plus pérenne de faire .net sous Linux

ah ok , je ne connaisssais pas, je vais regarder par la  
 
merci merci

Coucou
 
Messieurs, quelle est la best practice à l'heure actuelle pour générer des fichiers Excel (Open XML, .xlsx) relativement simples ?
 
Contraintes :
- environnement .NET Framework 4.8 (pas de Core, pas de Standard, pas de web)
- base de données MS SQL Server pour la source et je passerai par EntityFramework pour récupérer les résultats de mes procédures stockées et les ranger dans les IEnumerable<T> / List<T>
- ça sera une appli console qui tournera en tâche planifiée à intervalles réguliers (quotidien)
- budget financier : 0€
- budget temps : 5 jours
 
Il y a 5~7 ans, j'aurai sorti la carte ClosedXML voire OpenXML SDK, mais il y a peut être mieux désormais ?

Ok, merci pour ta réponse
L'avantage de ClosedXML c'est que je dois encore pouvoir retrouver des briques (création du workbook, filestream du classeur etc...).
 
Non en effet, ce sont des rapports quotidiens, faits sur le pouce pour une analyse vite fait. Un foreach sur des items en base de données avec un petit cumul sur la semaine ça ira très bien dans une feuille de calcul.

Pourquoi ne pas utiliser Dapper, plus light qu'Entity ?

Pour Excel, m'étant intéressé récemment au sujet, je suis tombé sur EPPlus : https://github.com/EPPlusSoftware/EPPlus
 
Et +1 pour Dapper.

Ca a quoi comme avantage Dapper sur EF Core ? Le côté light n'est pas pertinent dans mes use-case (je n'en suis pas à quelques Mo dans mes containers...). Et les benchmarks que j'ai vu étaient assez orientés, genre comparent une requête directe pour Dapper vs du linq pour EF, une base avec 100 lignes etc.

Merci pour vos réponses.

Pourquoi EF (classique, le projet est en .NET Framework 4.8) au lieu de Dapper ?
Tout simplement parce que le projet doit être le plus rapidement terminé, et que le temps que je me renseigne sur Dapper, j'aurai déjà mon EDMX, mes liens entre projets et mes premières requêtes Linq écrites et fonctionnelles

Sur un projet perso, avec du temps, j'aurai déjà commencé par du Core, et je me serai ensuite posé pour voir ce qui se fait d'autres qu'EF

Concernant EPPlus
Le fait qu'il soit devenu payant le disqualifie d'office

À titre perso, c'est surtout pour la simplicité d'utilisation. Une méthode d'extension sur DbConnection et basta. Les ORM qui génèrent eux-mêmes le SQL c'est pas ce que j'affectionne, je trouve plus clair que le SQL soit dans le code.

Il y a que dalle à apprendre pour dapper, tu ponds un POCO qui reçoit le résultat de ta requête et c'est terminé

Ah !
Faudrait que je regarde  
Comment se fait le mapping des champs et des types ?
C'est des SQL Adapter des années 90 ?

OK donc c'est plus pour la simplicité, argument valable effectivement

Mon souci c'est que vu ce que certains prestas ou même dans ma boite sont capables de pondre niveau SQL, le linq to SQL d'EF est pas forcément moins perf... A condition de ne pas être en lazy loading . Merci d'ailleurs à EF core d'être en eager par défaut

Pour les champs le mapping se fait par nom de colonne ou d'alias dans la requête. Pour le type, il faut que ça colle un minimum (mais ça marche avec un dynamic )

Je trouve que EF c'est très efficace si tu fais du Code First, sinon effectivement Dapper fait très bien le taf  

Merci à vous 2, je tâcherai d'y jeter un oeil quand même, ne serait-ce que pour ma culture perso

j'ignorais qu'EPPlus était passé sous license commerciale
 
Mais avec la dernière version LGPL : https://github.com/JanKallman/EPPlus
 
ça passerait pas ?
 
Car perso, les dernières fois où je devais faire des extract excel, le couple Dapper/EPPlus était terrible d'efficacité en terme de rapidité de mise en oeuvre

Pour la version commerciale, c'est sûr que c'est mort.
Ici (malheureusement) l'IT c'est système D, faut pas que ça coûte.
Déjà la licence Visual Studio 2017 Pro en 2018 je me prends des tacles à chaque réunion/séminaire
 
Par contre si y a une version LGPL pourquoi pas, d'autant que c'est destiné à de l'interne, pour monitorer un process.
 
Le seul et dernier souci va donc être de le temps de prise en main du truc
 
En tout cas, merci pour vos réponses les gars.
Ca me donne envie de bricoler un peu de mon côté pour découvrir.

 
 
Fini les missions ou tu passes pour un héro en virant tous les lazy loading  

Bonjour à tous
 
Utilisez-vous EF Core 3 ? Je suis en train de faire une migration de projet .Net Core 2.2 vers 3.1 et je rencontre deux problèmes sans vraiment arriver à trouver de réponse sur le net : mes recherches tournent en rond.Je ne connais pas grand chose à Entity Framework (et globalement, je n'aime vraiment pas les ORM... mais ça on s'en moque car ça change pas mon soucis)Ah et pour info je viens d'arriver sur ce projet chez un nouveau client, donc je vais pas tout refaire de suite.
 
Mon premier soucis est que j'obtiens à de nombreux moment le message suivant, qui semble plutôt explicite...

... sauf que je n'arrive pas à trouver quels sont ces requêtes concurrentes : comment procéder ?
J'ai vérifié que toutes les méthodes async étaient bien await.
Notons que j'ai diminué le nombre d’occurrence de ce soucis en passant l'enregistrement de mon dbContext de Scoped à Transcient, même si ça ne me plait pas trop... puis en passant l'enregistrement de tous les repository également en Transcient, le problème semble ne plus se produire.
Auriez-vous des suggestions ?
 
------------------
 
Second soucis : j'ai quelques requêtes EF Linq qui ne passent plus en exécution server-side (>'could not be translated') alors qu'elles devraient être supportés : cela concerne des queries utilisant .Contains() dans leur expression. Exemple :

J'ai pour le moment contourné le soucis en faisant une évaluation client-side via await _dbContext.Set<TEntity>().ToListAsync() puis en appliquant un .Contains() sur le résultat, mais on perd beaucoup niveau performances puisque toute la table est ramenée dans l'appli.
Quand je cherche des infos sur ce soucis, je trouve bien sur github des bugs côté EF Core sur le .Contains() mais tous semblent avoir été résolus.
Des suggestions ?

Faut voir si t'as besoin du scope "Scoped" dans ton appli ; https://docs.microsoft.com/en-us/as [...] -lifetimes
En gros, l'utilisation de Scoped peut poser des soucis si tu fais des singletons ou que tu fais du static dans tes instances Scoped (cf la doc ci-dessus). Donc ton pb pourrait venir de là. Utiliser Transient ne pose pas de souci particulier, on l'utilise beaucoup chez nous.
Après, pour un contexte de base de données, ça peut avoir du sens de l'enregistrer en tant que Singleton aussi non ? Mais dans ce cas, ne pas stocker la connexion à la DB comme static ou quoi dans ton instance.

Aucune idée pour la 2ème question en revanche.

EDIT : toujours pour la 1ère question, ce post de SO illustre bien les différences de scope : https://stackoverflow.com/questions [...] ifferences Notamment entre Scoped et Transient, qui vont se marcher sur les pieds entre 2 services pour une même requête si tu as du static dans ton instance.

EDIT 2 : ah ba : https://entityframework.net/knowled [...] -completed

Merci Taiche
Je vais déjà lire ça, c'est vrai que ce n'est pas une notion que je maitrise vraiment ça pour le coup...

Ba j'avoue qu'on utilise très peu (jamais ?) Scoped dans nos applis ici, donc j'en savais pas beaucoup plus avant de lire les liens ci-dessus

1er point : ça ressemble à un pb de parallélisme : ton repository doit appeler dans 2 méthodes différentes le contexte, qui est partagé. Essaie avec un lock pour voir. Perso j'utilise Mediatr, ça évite ce souci.
 
2° point : pas de souci de mon côté, mais je suis sous EF 3.1. Visiblement un bug existe en 3.0, je ne sais pas si c'est ton cas. A voir aussi le type de ton TPrimaryKey en pratique.

Je continue d'investiguer. Faut que je voie comment activer les logs verbeux pour EF, ça devrait peut-être m'aiguiller ?
 

Dans l'un de mes cas de crash, IEnumerable<TPrimaryKey> est un tableau de string (System.String[])
Je suis avec EF Core 3.1.7, le bug ne devrait plus exister. Il faudrait que je reproduise le cas dans un POC pour le soumettre je pense...
 
 
EDIT : texte edité -> c'est IEnumerable<T> qui est un tableau de string et non T qui est un tableau de string

Perso j'encadrerais déjà de logs les requêtes avant d'activer les logs d'EF. Tu verras déjà l'enchainement et pourras confirmer si c'est deux appels en //. Après je dois avouer que je ne sais pas si les logs EF sont verbeux, peut-être que ça reste lisible ?
 
 

Avec le string[] je vois mal comment ça pourrait être traduit en SQL, pour moi c'est juste pas supporté. Si tu as un int / Guid pour TPrimaryKey et toujours le problème, là ça sera un bug du framework effectivement.

C'est ce que j'aimerai éviter vu la taille de l'app   mais j'ai peur de ne pas pouvoir y échapper
 

ça se traduit simplement par :

 
Non, là column_name est un VARCHAR, donc TPrimaryKey est dans ce cas un string, ce qui est en effet simple. Si TPrimaryKey est un string[], ça devient impossible. Pour simplifier : GetByIdAsync(IEnumerable<string> ids) est OK pour la translation de requête, GetByIdAsync(IEnumerable<string[]> ids) ne l'est pas

heu... oui, non, oui... je suis tout à fait d'accord avec toi mais en fait j'ai dit un bêtise    
Ce n'est pas TPrimaryKey qui est de type System.String[] mais bien IEnumerable<TPrimaryKey> ids

Ca commence à être tendu donc. Dernière hypothèse TEntity.id est bien un string aussi dans ce cas ? Dans le cas contraire, possible que le cast ne soit pas géré. Genre string[].Contains(string) se traduit, string[].Contains(object) non