Reprise du message précédent :

 
Du coup tu as fait quel choix?
 
J'ai toujours utilisé autofac de mon côté

J'aime bien autofac.

Autofac est pas mal en effet. Ici on utilise Castle/Windsor, mais c'est overkill pour ce que l'on fait et me semble lourd à charger

Je suis parti sur autofac également, plutôt simple et efficace j'ai pas à m'en plaindre pour l'instant

J'ai juste dû creuser sur IIS qui host par défaut uniquement des services WCF avec constructeurs sans paramètres...
Faut faire son propre service host factory mais ça se fait, si y en a qui veulent plus de détails je peux partager

Resharper 2016.3 out (avec le reste de la famille jetbrains) !
https://blog.jetbrains.com/dotnet/2 [...] -released/
Support de VS2017 / C# 7, mais surtout pas mal de trucs sympas dans la génération de code .
Et des trucs intéressants dans DotTrace aussi !

 
Pour initialiser un conteneur de dépendance (ou n'importe quoi d'autre d'ailleurs) il y a aussi a une solution à l'arrache qui fonctionne très bien sous IIS 7, c'est de mettre dans le dossier App_Code une classe quelconque avec une méthode ayant pour signature :

Ca fait la même chose que le Start d'un global.asax.

 
Tiens petite question par rapport a resharper, tout le monde me dit que ça consomme énormément de RAM... déjà utiliser pour me confirmer ou infirmer cette info?

Je considère que VS et un gros projet ça bouffe de toute façon déjà énormément de RAM .

Sur un PC décent (i5 ou équivalent, 8Go de RAM) ça fonctionne très bien même avec des projets énormes.
R# ne me parait pas lourd par rapport à ce qu'il apporte !
Faut éventuellement penser à désactiver le "Solution wide analysis", ça ne sert pas beaucoup et ça consomme à mort.

edit : faut voir aussi que parfois JB ont tendance à prendre leurs clients pour des bêta testeurs, les premières versions de R# 2015 c'était la cata niveau perfs et stabilité par exemple, ça ne doit pas aider côté réputation. On avait du en parler ici à l'époque et moi j'ai pas mal gueulé sur leur bugtracker, le problème était unanimement reconnu et leur image en a souffert.

edit : et le Continuous testing, j'ai pas vérifié l'impact sur les perfs mais c'est aussi désactivé chez moi.

 
Ok merci, oui j'ai eu beaucoup d'écho avec VS2015. Merci de la réponse

Pas VS2015, mais Resharper sorti en 2015 (avant qu'ils mettent l'année dans le nom).
edit : c'était la version 10 il me semble.

Bonne année les C-sharpeurs !

Je suis en plein dilemme...
Nouveau projet assez costaud chez le client, on me laisse libre du choix des technos. On va dépoussiérer la stack technique !

Pour cette nouvelle appli le front sera en Angular 2.
Je n'en ai jamais fait et ne suis pas super à l'aise avec le JS en général : je suis orienté back-end, je viens du monde de l'électronique
Mais bon, je m’appuierai sur un dev bien plus à l'aise que moi en front-end.  

Pour le back ça sera du Web API. Ça on maîtrise.
Mais là j'hésite entre rester sur du .Net 4.6 ou carrément passer à .Net Core 1.1 !
C'est très tentant, mais ça me fait un peu flipper... beaucoup de choses à mettre en place.
Je regrette de pas m'être penché dessus il y a déjà quelques mois  

Sinon jusqu'à aujourd'hui, niveau ORM, je n'ai manipulé que NHibernate. Est-ce complexe de passer à EF 6 (ou Core ) ?

Dans l'équipe j'ai entre autre deux juniors. En entendant les technos que l'on va prendre, eux ils sont comme ça : , moi je suis comme ça : (ça fait peur tout ces changements !)

 
Felicitation
 
Je dirais que le choix du stack technique doit prendre en compte differentes composantes:
- La deadline du projet (ou du MVP)
- la taille de l'équipe
- Les conaissances techniques et XP de chacun de tes membres. Ca determinera la learning curve
- Le niveau d'exigence du projet (si avoir un lancement un peu bancal c'est pas trop grave ou faut du solide tout de suite)
etc...
 
En gros passer sur un stack que personne ne maitrise dans ton équipe, couplé a une tight deadline = de nouvelles techno, code mal organisé, specificité des technos non maitrisées, pas de visibilité sur la maintenabilité = une dette technique énorme des le depart
 
Donc a part si t'es large niveau timing, que le projet est pas trop critique (ou que tu as des membres carrement costaud dans ton équipe) je ne m'engagerais pas sur du .Net Core (applicable pour les autres briques)
 
Dans l'absolu le .Net Core je ne prendrais ca pour aucun projet pour le moment, ils annoncent des breaking change a chaque release  
 
En tout cas good luck, et fait toi plaisir tout en controlant le risque

Ce qui m'attire dans le .Net Core, c'est le nombre de requêtes par secondes qu'il est capable d'encaisser.
La durée du projet est confortable, la taille de l'équipe raisonnable (1DA, 1 integ web, 1 lead front-end, 1 lead back-end, 2 dev juniors, 1 CP et on a encore un peux de ressources). Nous recodons une application de zéro : nous avons toute la partie fonctionnelle parfaitement décrite.

L'équipe est nouvelle, monté spécialement pour le projet. Je cherche encore le dev qui aura le rôle de lead sur le front (si un indep' ou presta en interco passe ici, MP moi ). C'est ce point qui me stresse un peu.
J'ai peur par contre des breaking change en effet dans .Net Core 1.1, même si on est en RTM

Je vois que les gens sont motivés pour s'auto former sur leur temps perso, quand il s'agit de nouvelles technos. Et les juniors, ils veulent en bouffer du Angular

EDIT : et la deadline n'est qu'un point placé pour avoir un repère, un but. Je pense que l'on à de la marge, mais on pourrait déborder que ce ne sera pas trop un soucis.

 
Tu as une attente particuliere en terme de nombre de requetes a supporter ?
De plus je dirais que le nombre de requete ne tiens que si derriere tu as le stockage qui supporte. A part si ton application ne tape pas dans une BDD, ce dont je doute, ou alors tu as prévu egalement ce qu'il faut a ce niveau
 
Ca serait interessant de décrire les volumes de données en jeu, le/les BDD, le volume attendu en terme de requetes HTTP etc..
A part pour un site grand public a grand traffic, .Net "classique" fait tres bien l'affaire
 

Pour les technos, tu peux aussi regarder le Tech Radar de Thoughtworks qui donne de bonnes billes sur les technos du moment (actualisé chaque trimestre). Angular, 1 ou 2, a une courbe d'apprentissage très sportive surtout quand on vient du back et qu'on a peu voire pas de formation front. Pour l'avoir vaguement constaté sur le terrain, pas mal de fronteux que je connais (et qui sont pas des fanatiques de l'un ou l'autre framework) sont passés d'Angular à React/Redux.
 
Idem que massanu pour .Net Core, la peinture est pas encore sèche, perso je le mettrais pas en prod.

Je fais du angular2 quasi quotidiennement maintenant.
Le plus dur c'est pas tant la techno qui commence à être pas mal fournie et stable (j'ai commencé avec l'alpha), c'est surtout la mise en place et maintenance de environnement de développement (et je parle même pas du déploiement en production ), de la gestion de version, à l'intégration continue.

Pour le reste, si on connaît bien la DI, et si on a une expérience dans le WPF voir carrément le MVVM, ça passe plutôt bien.

 
Niveau nombre de requête, nous pourrions ainsi diminuer le nombre d'instances de nos applications en terme de redondance. C'est une problématique que nous rencontrons de plus en plus. Nous sommes sur de l'application de paiement bancaire haute disponibilité (dans une toute autre dimension que la carte bancaire en terme de temps de réponse)
 

De mon côté, je vois de moins en moins de demande en React (point de vu commercial / appels d'offres / souhait des développeurs)
 

La partie software factory ne m'inquiète pas du tout. La mise en place de l'environnement va se faire par un gars qu'on à trouvé et qui commence à pas mal touché en angular2 (il est aussi passé par AngularJS et React)
 
On met de côté .Net Core pour le cœur de l'application pour le moment.

du trading haute fréquence quoi    

Hello par ici
 
Je viens de récupérer une tâche "marrante" au boulot
 
On a une vieille application, plutôt bien écrite dans le fond, mais avec quelques vieilleries largement dépassées.
C'est une application webforms en .NET 3.5, avec Spring 1.3.0, nHibernate 1.2.1, qui attaque une base de données SQL 2008 R2 et contrôlée par un SVN, le tout dans une solution d'une dizaine de projets au format VS2008.
L'appli demandait peu de support jusque maintenant, mais désormais, on a des projets pour elle, mais, comme toujours, pas assez de budget pour une refonte complète...
 
Je suis donc en charge de la migrer vers nos technos "modernes" ici, c'est à dire TFS 2012, Visual Studio 2015, .NET 4.5.2.
La consigne est d'y passer le moins de temps possible, donc sous-entendu interdiction de tout péter pour claquer un EntityFramework qui va bien
Je dois par contre prévoir de passer sur un pool en 4.0 côté IIS.
Côté BDD, nos serveurs sont toujours en 2008 R2, donc pas de soucis avec ça.
Idem pour la migration SVN > TFS qui est très simple et déjà opérée.
Côté cadavres, il y avait un projet de génération de packages d'installation MSI dans la solution qui n'est évidemment plus supporté. C'est pas grave, la chose peut simplement être supprimée puisque nous utilisons désormais un serveur de build distant pluggé à TFS (TeamCity), qui s'occupe de générer les livrables pour nous.
 
En réalité, les ~10 projets de la solution ont donc bien été migrés sans difficulté vers 4.5.2.  
A part quelques Warnings qui ont pu aisément être corrigés (ConfigurationSettings > ConfigurationManager par exemple), tout compile proprement...  
 
Le réel soucis vient de Spring qui semble ne plus du tout fonctionner : dès que je lance l'application, ma session de navigation est vide, alors que sur la version 3.5 qui tourne toujours, j'ai bien une belle session de navigation avec une dizaine de clés renseignées.
Evidemment, comme c'est Spring qui se charge de configurer mes logs Log4Net, ben j'ai absolument aucune idée de ce qui merde
 
Alors docteur, une idée ?
 

Nope
Un système de paiement

Resharper 2016.3.2 out !  
https://blog.jetbrains.com/dotnet/2 [...] -2016-3-2/
Ils sont au taquet les tchèques en ce moment, ça fait plaisir à voir vu le fiasco des versions de l'an passé.
 
DiB91 > alors c'était quoi la solution ?
Je t'aurai bien aidé, si je n'avais pas définitivement banni Spring.Net de mon existence  

 
Alors déjà, j'en suis arrivé à la même conclusion que toi
 
Pour mon soucis, j'ai mis en avant l'évident manque de connaissance et de documentation sur les versions récentes et leur support/implémentation dans les versions "modernes" des outils .NET Microsoft et ça a marché : on garde notre vieux tas de boue en 3.5 encore quelques mois... MAIS un gros projet de 60 jours de refonte en 4.5.2 / MVC 5 / VS2015 / VS TS / EntityFramework 6 / SQL + SSRS 2016 est prévu d'ici l'été 2017.  
 
Ils ont du en avoir marre de m'entendre râler et faire des vannes plutôt médiocres sur "Spring" et "nHibernate"    
Et puis surtout 3 jours là dessus pour arriver à une conclusion de rollback... c'est cher

Ah c'est à ce point .
J'aurais imaginé que t'aurais au moins bricolé pour débloquer les logs, ou pu te figurer ce qui se passe en débuggage...

Moi c'est il y a 7 ans que j'avais conclu ça, je pensais qu'entre temps le bousin avait pu s'améliorer, alors que pas du tout à te lire, ils ont juste rendu ça incompatible avec les environnements récents.

A propos de logging, y a encore des gens qui utilisent log4net ? Je sais que la fondation Apache a repris ça pour essayer de le sortir du formol où il marinait depuis quelques années mais je ne sais pas si ça a donné un truc utile. Moi j'utilise NLog sur absolument tous mes projets depuis des années...

Ben en fait l'instanciation de Spring ne fonctionnait pas avec les versions actuelles, même en envoyant tout ça sur un pool 2.0 classique (je parle même pas d'IIS Express 10....). J'ai passé une journée à essayer de bricoler des trucs pour faire démarrer le bouzin, mais ça n'a jamais rien voulu savoir. L'instanciation de Log4Net passant elle-aussi par Spring... j'étais d'office baysay côté log appli/db. Côté IIS j'avais pas d'erreur très parlante, juste la nullref lorsque j'accédais à ma session dans le global.asax. Sans plus d'info que ça, je sais pas trop où chercher pour trouver plus d'info sur l'erreur

J'ai passé une 2e journée à mettre à jour 1 par 1 tous les packages utilisés vers des versions plus récentes et à installer un Log4Net autonome, et là j'ai obtenu des choses un peu plus parlantes : j'ai pu obtenir de la data depuis ma DB via nHib et lancer mon log4net, mais toujours impossible de lancer l'appli web avec Spring dedans, même migré en 2.0.x
Au final, j'ai reçu pour consigne de ne pas toucher aux packages vu les évidents risques de régression que ça allait apporter...

On partira donc sur une refonte complète dans l'année, avec migration des données (ça, ça va c'est clairement jouable, le catalogue fait 2 Go pour moins d'une dizaine de tables, et ça avait été bien pensé au début, EF ne devrait pas trop galérer).

EDIT : Ah ben tiens, joli crosspost Log4Net
Nous on utilise plutôt du maison ici, voire Elmah sur 1 ou 2 applis spécifiques, mais oui, on a aussi du L4N qui traine.
Je dirai même que c'est la solution qui s'impose quand on démarre un chantier express vu la facilité avec laquelle on obtient rapidement des traces

Jamais utilisé ELMAH. La forte orientation http me rebute même si selon l'usage ça peut clairement vu être comme un avantage.
 
Les points positifs (rapidité de mise en oeuvre) que tu trouves à log4net sont ceux que j'apprécie avec NLog : tu ajoutes ta dépendance par nuget, tu claques ton nlog.config à la racine du projet avec tes appenders/layouts habituels, et en trois minutes t'as une solution de logging performante, fiable, et hyper extensible.

Pareil je suis sur nlog j'en suis très content.

+1  

Salut à tous,

J'aimerais savoir si certains d'entres vous aurez des livres en architecture/algo dans les techno de chez CroSoft, ou voir même sur l’intégration continue avec TFS.

J'ai acheter un bouquin nommé "Adaptive Code Via C#" de Gray McLean Hall qui explique comment créer des applications en utilisant les méthodes agiles et le pattern solide.

Je me suis pris la main dans le sac a réussir la lecture du livre et vu que j'avance assez vite, je risque d'être en rade dans peux de temps.

Et comme j'ai trouver ça vachement instructif, je me suis dit, au lieu de cherché des heures sur Amazon j'allais venir ici poser la question

Yes pour nlog aussi, j'ai lu énormément de bien à son propos, juste je n'ai pas encore essayé.
Pour la rigolade, il me semble que désormais quand on installe la dernière version de Log4Net, ça ajoute nlog par dépendance

On a tout sous log4net mais j'envisage de migrer plusieurs applications vers NLog et de centraliser les logs dans une DB (chaque app est déployé en X instances sur N serveurs, X et N >> 10)

La migration sera simple vu que l'on a une abstraction des framework de logging : aucun soucis pour faire tourner plusieurs loggueurs simultanéments (et c'est déjà le cas pour certaines de nos apps). Par contre ça limite l'accès à certaines fonctionnalités avancées, mais je n'ai jamais vu personne les utiliser dans aucune mission

Pour faire de l'injection de dépendances, quel est le fmwk à la mode ?
Je suis habitué à Castle Windsor, mais s'il existe aujourd'hui des trucs un peu plus léger tout en restant pas trop complexe à mettre en place, je suis preneur. Que pensez-vous de Ninject ?

Autre question, comment hébergez-vous vos applications SPA ? Porté par une application .Net dans IIS ? Utilisation d'un serveur web Apache ?

1) Je vote Autofac. Question déjà débattue ici il me semble (cherche )
 
2) C'est quoi le rapport entre SPA et le machin qui héberge ? C'est la techno de ton appli qui oriente ça, pas la façon dont elle s'affiche

1) En effet, j'avais déjà posé la question il y a plus d'un an je crois   . J'étais parti sur Autofac justement.
2) Oublié de préciser la techno : Angular2. Il y a pleins de façons d'héberger ça

Nous on va partir sur IIS pour notre appli angular2.

En posant la question à des collègues sur d'autres missions, plusieurs utilisent ou prévoient d'utiliser un projet .Net core pour hoster l'application

Pareil, on a quelques applis Angular (pas 2 par contre), et elles sont hébergées dans nos IIS.
 
Concernant l'injection de dépendance, déjà, je downvote Spring
Ensuite, moi, je vote Unity que j'ai eu l'occasion d'utiliser en web (ASP .NET MVC en mode API) et en en WPF (avec MVVM Prism).  
Facile et rapide à mettre en œuvre, et très bien documenté

Autofac est nettement plus light qu'Unity.

Je vais me renseigner, je n'ai jamais essayé

De ce que j'ai pu tester, oui autofac est bien plus light
J'aime bien quand même Windsor Castle, mais il est un peu moins simple à mettre en place

Dites vous utilisez quoi pour manipuler des fichiers excel côté serveur ?
Parce qu'on utilise MS Acces database engine mais ceux qui gèrent l'infra ralent un peu parce que

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)