Reprise du message précédent :
Ouep, je confirme, tout ce qui est basé sur l'interop (automation), c'est à déconseiller, tout particulièrement parce que ça impose l'installation (et donc l'achat) d'une licence Office sur chaque serveur web...
 
Pour mes développements, j'utilise :
- ExcelWriter, de la suite OfficeWriter de chez SoftArtisans pour la manipulation et création de documents Excel <2003 (fichier binaires XLS)
- ClosedXML basé sur le SDK OpenXML officiel pour la manipulation et la création de documents Excel >2003 (fichiers Open XML XLSX)

J'vais voir parce que j'ai des doutes que ce soit accepté chez nous si il n'y a pas de support officiel.

Ah ben dans les 2 cas, il y a une dll à ajouter.
 
Pour ClosedXML, c'est dispo gratuitement sur Nugget, il y a une communauté assez active, et ça s'appuie sur le SDK OpenXML (qui suffit peut-être d'ailleurs, j'ai jamais essayé pour Excel) fourni par Microsoft, donc plutôt bien documenté et "propre". Attention par contre, c'est assez difficile à faire cohabiter avec certains plugins. J'ai été emmerdé par le passé avec une appli en .NET 4.0 qui embarquait un autre package qui imposait une version plus ancienne d'OpenXML, incompatible avec 4.x. Bon, ça devait être un cas bien particulier quand même...
 
Concernant ExcelWriter, là, c'est pas sur Nugget. C'est une PME qui vend ça sous licence, c'est assez cher apparemment d'après les gars avec qui je bossais avant. En plus SoftArtisans la jouent un peu à la JetBrains : généralement une licence te donne accès à une version spécifique du plugin, et pour les prochaines mises à jour / sorties majeurs, tu raques à nouveau. Côté SDK, c'est un jeu de DLL à installer sur les postes de développement (un setup.exe est fourni avec la clé) et à embarquer dans la solution, donc besoin de rien de plus côté serveur. Côté support, si j'ai jamais vraiment eu besoin de chercher de l'aide, je suppose que qui dit licence payante, dit accès à un support client, une doc, voire une formation en cas de besoin

On a une équipe qui utilise Aspose. C'est cher, ça a l'air puissant, et ils veulent pas partager leur licence avec les autres services  

Mais au fait, je parle de ça : https://www.microsoft.com/en-us/dow [...] x?id=13255
Ca ne nécéssite pas l'installation d'office sur le serveur.

Salut,
 
j'ai pas fait ça depuis des années mais à l'époque j'utilisais NPOI.
 
Aucune idée de si c'est toujours pertinent aujourd'hui.
 
https://github.com/tonyqus/npoi/
 
++

Bordel, j'ai 3 applications qui ont des problèmes différents avec la manipulation de fichiers excel.
Outil de

 
En tout cas, par chez nous on l'utilise encore, ça ne nécessite aucune installation supplémentaire.
 
Quelques méthodes d'extension par dessus pour faciliter l'usage, et ça roule.

Hello,
 
je dois faire une petite appli client lourd pour de l'outillage.
ça fait une éternité que j'ai plus suivi ce qu'il se faisait. On est toujours sur du WPF + MVVM ? Il y a un framework incontournable ou bien vanilla ça le fait aussi  ?
 
J'aurais bien testé de l'UWP mais target windows7

Ouep, côté application "de bureau" Win32, on est toujours sur du WPF.
Vanilla ça marche bien et c'est facile à prendre en main, mais si tu connais déjà un bon moteur MVVM (Prism + Unity, par exemple), tu seras le roi du monde
 
Si c'est pour un besoin rapide, tu peux aussi très faire du Winforms, encore parfaitement supporté dans les dernières versions du SDK

Merci bien !
 
C'est parti pour s'éclater en xaml alors

J'ai vraiment kiffé faire du MVVM avec Catel à l'époque

Pour ceux qui ont loupé la news, VS 2017 est dispo en version finale.
 
Lien direct vers la version Community : https://www.visualstudio.com/thank- [...] ty&rel=15#
 
Pas encore installé de mon côté.

 
Je l'ai installer et utilisé en RC, je trouve que l'intelisense est plus sympas ainsi que le rendu du code.
 
Le nouvel installateur est vachement bien, je suis passé de la version RC à finale sans aucun problème via l'update que proposé VS.
 
Après  je n'ai pas encore eu l'occasion de tester d'autres fonctionnalité.

Il n'y a pas un problème avec l'aide et les commentaires de méthodes/classes chez vous ?

 
Y'en qui utilisent Dapper ici ? C'est bien ?

Sur ce site, Angular n'a jamais eu la cote.

De mon côté on s'est mis à angular1 ya un peu plus d'un an et Angular2 tout juste.
Et j'entends plus parler que de ça autour de moi / dans mes contacts pro.

Et de plus, on bosse avec des intégrateurs graphiques qui ne trouchent qu'aux pages HTML, j'ai l'impression que React n'est pas trop idéal pour ce genre d'approche, il vont devoir bidouiller les Js

   
Oui c'est très bien mais ça dépend ce que tu cherches aussi. En gros, ça ajoute un mapping automatique par-dessus ADO.Net ; tant que les champs de tes classes matchent peu ou prou les noms de colonnes (ou les alias via "select machin as truc" ) et que ça te dérange pas d'avoir du SQL dans tes .cs, ba je conseille clairement Dapper. Si t'aimes ne pas voir le SQL, faire du mapping compliqué, etc... bin ça risque de t'emmerder.
La page Github est bien faite pour voir comment ça fonctionne. Fais-toi 2-3 tests chez toi et tu verras si ça te convient. Chez nous, on va virer l'ORM pourri et le remplacer par Dapper.
En général, comme la plupart des applis font des CRUD bêtes et méchants, Dapper suffit carrément.

idem ici. J'ai prospecter les boites ces derniers temps, et angular est clairement ds le top 3 des technos recherchés. Pour pas dire en 1 au global. Je suis aussi a peu près certains qu'ils ne savent pas trop de quoi il retourne en vrai ds la plupart des ssii, mais ca change pas d'habitude on va dire ^^

 
Un Archi de chez nous le pousse pour un projet.  
 
Moi j'ai toujours utilisé EF même pour des trucs très simple, et je ne voit pas l'intérêt de Dapper, à part peut être pour les perfs.  
Je crois que ça fait au moins 5 ans que j'ai pas fait de requête SQL dans un projet .NET et je m'en porte très bien. Depuis EF, l'accès aux données n'est plus un problème, ni une perte de temps, et ne pose plus de problème de maintenance.
 

 
C'est vrai qu'un choix répandu n'est pas toujours le mieux. J'avais toujours entendu parler en bien d'emberjs, mais pourtant j'ai jamais croisé quelqu'un l'ayant mis en prod
Et personne veut en entendre parler.
 
 
En plus, quand je vends des projets, des que tu dis qu'il y a de l'AngularJS, les clients sont    

Tu me demandes si c'est bien, je te réponds Mais à titre perso, j'ai jamais vu l'intérêt des usines à gaz comme EF ou NHibernate pour faire du CRUD idiot. Une lib légère fait le boulot et y a 0 montée en compétence. Plutôt que de demander la valeur ajoutée de Dapper, demande-toi la valeur ajoutée d'un gros ORM.
Pour rester sur la discu Angular, c'est un peu comme demander pourquoi faire du HTML simple alors qu'Angular est top. Ba si c'est pour une pauvre page statique, je préfère poser la question à l'envers.

Pas de méprise, j'apprécie ta réponse  

J'explique justement que je suis resté coincé sur EF, peut être a tort  

 
Je connais une boite qui a migrer de Angular 1 à emberJs et qui a mis ça en production.
Le responsable technique de cette boite m'a dit que la migration c'étais très bien passé et que l'équipe au final préférer emberjs à angular

Ah pardon, j'avais mal interprété ton message
De manière générale, j'essaie maintenant d'éviter les gros frameworks pour des utilisations (qui semblent) simples ou, en tout cas, de comprendre comment ça marche et voir si c'est overkill ou pas. Ca simplifie souvent la vie

Resharper 2017.1 out !
https://blog.jetbrains.com/dotnet/2 [...] te-2017-1/
 
Apparemment beaucoup de choses en lien avec VS2017 et .Net Core, support d'AngularJS 2, améliorations du support C++ et probablement quelques bugfixes.
Rien qui fasse rêver dans DotTrace et DotPeek, c'est pas demain que j'aurai les features que j'attends

C'est Resharper qui transforme les "=>" en "⇒" ?

Comment ça, où ?

C'est pas une question de "plus intéressant ou non" mais de "légal ou non".
 
Si tu développes pour le plaisir / dans un cadre open source / en tant qu'étudiant / sans faire de bénéfice / pour une TPE / [etc], alors oui clairement un VS Community + R# fera plein de choses qu'un VS Pro seul ne fera pas, vu que VS Pro est à peu près équivalent en terme de fonctionnalités à VS Community.
 
Mais si tu bosses pour une grosse boite (cf les critères de MS pour la version Community, qui sont déjà assez souples je trouve ) alors tu es de toute façon obligé d'acheter une licence VS Pro.

Dans la 1ère vidéo de ton lien montrant du code c#
 

Ah oui. C'est la première fois que je vois ça, je suis sous VS2015 (ou 2010 contre mon gré selon le projet/client) et R# 2016.3 donc je ne peux pas te dire si c'est VS2017 ou R# qui amène ça.

Petite question au passage, j'ai un client qui utilise SVN.. ça fait un bail oui
 
Quel est le meilleur (léger et peu intrusif) plugin SVN dispo pour VS2015 svp ?

Perso je suis toujours sous SVN aussi, et pour VS j'utilise depuis une bonne décennie AnkhSVN ( https://ankhsvn.open.collab.net/ ). La fréquence des updates n'est pas énorme mais pour moi jusque là ça fonctionne parfaitement bien et c'est léger.

Pour le Diff j'utilise tout bêtement Winmerge, bien configuré ça fait très bien le job mais il y a d'autres possibilités. Pour le shell, j'utilise TortoiseSVN.

En alternative à AnkhSVN il y a VisualSVN https://www.visualsvn.com/visualsvn/ que je n'ai jamais essayé et qui a l'air de faire pleins de trucs en plus.
J'utilise VisualSVN Server du même éditeur pour gérer mon serveur SVN, et vu que j'en suis super content je pense que si le client pour VS est du même niveau ça doit être top.

Et on peut dire ce qu'on veut sur l'ancienneté de SVN, je trouve toujours qu'en tant que contrôleur de code source c'est un million de fois mieux que TFS

Et on peut dire ce qu'on veut sur TFS, je trouve toujours qu'en tant que contrôleur de code source c'est un million de fois mieux que GIT/SVN
 
 
Comme quoi, tout est question d'habitude d'utilisation

on est en train de migrer de TFS à VSTS avec GIT c'est quand une philosophie très différente, dire que l'un ou l'autre est un million de fois mieux c'est un con le principe des pull request est quand meme bien fouttue pour les code review asynchrone.

Je trouve le code revues asynchrone non pertinent dans une équipe de dev.
Par contre, pour du open source oui ça l'est

On.mix les deux, quand la modif est petite et/ou urgente, ca permet de se concentrer sur les trucs plus touchy en revue physique

Je vois qu'on a des fans de TFS dans l'assistance, mon message a fait réagir

Merci . Moi aussi je t'aime beaucoup tu sais
Au passage tu noteras que je n'ai en aucun cas écrit que l'un est objectivement meilleur que l'autre à quelque ordre de magnitude que ce soit, vu que le caractère personnel et subjectif de ma phrase était très clair.

Pour rester sur le débat (vu que ça fait parler), je n'ai pas envie de détailler pourquoi mes expériences avec TFS ont étés exaspérantes. Mais pour citer quand même en vrac :
- mode online lent et contraignant dès qu'il y a un peu de latence réseau genre VPN,
- mode offline buggé (ne voit pas toujours les fichiers modifiés, même quand c'est fait avec VS) et qui m'a déjà fait perdre totalement des sources. Sans parler du bordel que ça occasionne quand on bosse à plusieurs.
- switch entre les deux chiant
- intégration au shell moisie (plugin buggé)
- outils de diff/merge très moyens
- administration bien pénible
- indisponibilité par la GUI de fonctions aussi connes que "extraire les fichiers modifiés dans tel changeset". Obligé de passer par des lignes de commande ou des trucs comme http://stackoverflow.com/a/35689473/461444
Notez que je n'ai pas testé la dernière version, j'ai déjà bien subi tout ça avec surtout le 2008 / 2010 pour des clients différents et je n'ai aucune envie de poursuivre l'expérience avec les nouveaux millésimes.
Le SEUL concept que j'ai trouvé utile dans TFS c'est le Shelve, sauf que manque de bol ils n'ont fait qu'effleurer l'idée avec un truc bien restreint de partout (ex : pas de merge. Si c'est pour avoir un truc aussi limité autant foutre un zip dans un coin).

Je fais l'impasse sur tout ce qui vient autour (workitems, bugtracker, ALM, intégration avec Sharepoint et cie), comme je disais dans mon post plus haut c'est du contrôleur de code source que je parle.

Donc je préfère continuer d'être con et utiliser des outils gratuits, éprouvés, riches, portables, intéropérables, performants et aboutis comme SVN (malgré ses limites : pas de DCVS, pas de commit partiel, etc), Git, ou Mercurial

Maintenant si vous aimez TFS j'en suis bien content pour vous

Et ben, je n'ai absolument jamais eu aucun des soucis que tu remontes avec TFS. Moi j'ai pris à partir de la 2010 par contre, donc peut-être que ça s'est amélioré avec les dernières versions
 
En tout cas je confirme que, bien évidemment, tu peux merger un shelve avec le reste du code hein. C'est évidemment source de conflits qu'il faut minutieusement observer avant de balancer n'importe comment au serveur, en utilisant, par exemple, les outils de versionning et de comparaison intégrés parfaitement au point
Ca m'arrive souvent, dans mon équipe de 4-5 développeurs, quand on fait de l'évo ou de la veille, de devoir shelver des POC pour les ressortir quelques mois plus tard, et ça s'est toujours bien passé, avec quelques heures de concentration pour tout remettre en place.
 
Côté config serveur, ça, j'avoue, je connais pas du tout, et ça a l'air d'une bonne chiée en effet, vu comme les sys admin se plaignent tous les 2 jours.  
 
Pour moi, le plus chiant jusque maintenant c'était les pending changes orphelins que laissent trainer les collègues quand ils changent de PC, pètent leur workspace ou partent de la société
Les fichiers lockés sont alors perdus, surtout si la solution était configurée en single checkout
 
Sans ça, je me sers quotidiennement aussi de la partie "agile" (workitems, boards...) et c'est vrai qu'il manque quand même 2-3 trucs pour être 100% utilisable en gestion de projet (la partie suivi du travail est laborieuse...), mais c'est complètement personnalisable, donc adaptable au workflow d'une équipe de dev.
 
C'est comme pour toutes les infra IT, il faut prendre le temps de l'appréhender, se former, faire venir des mecs qualifiés, admettre que ça se configure pas en 35 minutes autour d'un café. Mais au final, franchement, SVN à côté, c'est complètement dépassé et dangereux à utiliser en équipe (le mot est choisi à juste titre je pense).
Je ne connais pas Git par exemple, jamais utilisé.

Me rappelle plus trop de pourquoi les Shelve m'avaient paru une bonne idée mais bâclée dans l'implémentation.

Les commit (checkin si tu préfères pour reprendre le vocabulaire MS ) oubliés en chemin ça c'est du PEBKAC, pas la faute de l'outil par contre

Mais je peux te dire que pour mon client actuel avec lequel je bosse depuis 2 ans sous VS2010, je me tape TOUS les bugs dont j'ai parlé sur le mode online/offline (ça c'est le pire), le truc bien lent, etc.
Et avant ça j'avais eu droit à tous les soucis d'admin / branching sur d'autres interventions.
edit : et j'ai aussi eu deux fois des bugs démentiels sur le tracking d'objet dans TFS, genre deux fichiers dont le contenu côté serveur avait été remplacé par des trucs qui n'ont rien à voir et que je n'ai jamais checkin, genre un bordel en binaire et des sources sans aucun lien

Pourquoi ça serait "dangereux" un SVN . Il y a des limitations très claires que je reconnais évidemment, mais avec une bonne politique de backup et une gestion saine du repository c'est tout à fait robuste (jamais vu un repo SVN corrompu, la seule fois où c'est arrivé c'était du bit rotting, et il a suffit d'aller choper une copie de la rev en cause dans un backup pour réparer ça sans aucun souci).
Et on peut faire pas mal de chose avec les hooks. Le truc qui manque (en natif) c'est un équivalent au checkout en lock partiel ou exclusif pour être "averti" qu'un fichier a changé mais sinon on a à peu près tout et avec une bonne utilisation (genre éviter de faire un Update seulement tous les 15j) c'est pas un problème.
Je ne dis pas que c'est un bon choix aujourd'hui, mais de là à dire que c'est "dangereux" il y a un sacré pas.

Git est bien plus difficile à maitriser à cause du côté DCVS, le "cycle de vie" d'un commit est bcp plus complexe que "on pousse, c'est sauvé sur le serveur pour tout le monde". Perso je ne le conseille pas si on n'a pas besoin des fonctions avancées.
Mercurial est plutôt sympa par contre.

 
Désolé je voulais dire "c'est un peu con"