Contrairement à ce que la francisation du mot anglais « thread » laisse entendre, la création de threads n’est pas vraiment sans conséquences. Si vous démarrez beaucoup de threads réalisant des tâches simples dont le seul objectif est d’être asynchrones, le coût de la création va significativement nuire à vos performances. ThreadPool résout ce problème en offrant un ensembe de threads déjà initialisés, et qui n’attendent que vos instructions pour démarrer.

Si théorie ne vous suffit pas, n’hésitez pas à consulter l’article de Vko sur le sujet : il y a mesuré la différence de performance entre l’utilisation de Thread et de ThreadPool. C’est édifiant.

Article original publié sur Nexdotnet’s Blog © 2012
Sauf utilisation du droit de courte citation, cet article est soumis à la licence Creative Commons by-nd 2.0 France

LinqPad vous permet de lancer vos requêtes sur vos bases directement en LINQ, mais ce n’est pas son seul intérêt. LinqPad supporte entièrement LINQ jusqu’au framework 3.5. A vous les joies de LINQ to Objects, LINQ to XML et Entity Framework !

LinqPad est gratuit et n’a pas besoin d’être installé.

Article original publié sur Nexdotnet’s Blog © 2012
Sauf utilisation du droit de courte citation, cet article est soumis à la licence Creative Commons by-nd 2.0 France

Je pense qu’on passe tous par ce genre de phases de temps en temps. Vous savez, quand vous réalisez que ce nouveau truc que vous avez appris est génial et que vous vous mettez à l’implémenter partout. Ca devient votre plus grande obsession : comment tirer partie au maximum de ce truc.

D’un coup, tous vos objets sont anonymes, tous vos callback sont lambda, toutes vos méthodes sont génériques, la plupart de vos processus sont asynchrones, tous vos développement lourds sont en WPF, vos services web sont WCF… même si ça ne vous sert à rien et que potentiellement, cela met en danger l’intégrité de votre application.

Le pire, c’est que vous êtes contagieux. Vous écrivez des articles, vous en parlez à vos copains développeurs, vous en parlez même à votre petit-cousin de 2 ans et demi (qui, à n’en pas douter, sera un grand développeur .NET un jour).

Il est très difficile de résister à cette tentation, même pour un développeur expérimenté. Et ça ne touche pas que les développeurs .NET je pense. Alors quand vous sentez que vous êtes atteint, n’oubliez pas de vérifier que votre gestionnaire de code source vous permet de revenir proprement en arrière !

La dernière fois que ça m’est arrivé, c’est avec WPF. J’ai commencé à reprendre tous les développements en client lourd que je faisais chez moi pour les transformer en WPF. J’ai fait chauffer Expression 2 mais comme je ne suis pas vraiment graphiste (ok, pas du tout), l’intérêt ergonomique de la migration était… discutable ^^

Et vous, quand avez-vous craqué la dernière fois ?

Article original publié sur Nexdotnet’s Blog © 2012
Sauf utilisation du droit de courte citation, cet article est soumis à la licence Creative Commons by-nd 2.0 France

Pour répondre à cette question, il faut comprendre les grandes tendances actuelles en matière de développement :

• Les développeurs  se tournent de plus en plus vers des langages déclaratifs, qui leurs permettent de se concentrer d’avantage sur ce qu’ils doivent faire et pas sur la façon dont ils pourront rendre leur code impératif fonctionnel.
• Les langages dynamiques tels que Php, Javascript, Ruby… connaissent un succès qui ne se dément pas. La simplicité du développement, le typage implicite et l’absence de compilation y sont pour beaucoup.
• Paradoxalement, on observe un intérêt sans cesse renouvelé pour les langages statiques. Ils apportent leur lot de robustesse, de performance et d’outils intelligents comme IntelliSense dans Visual Studio, ainsi que, généralement, une meilleure sécurité lors de la montée en charge (le code étant compilé, il est moins évident de passer à côté d’une erreur, même si le projet fait plusieurs millions de lignes).
• Enfin, un besoin important d’économiser de l’énergie en privilégiant les technologie multicoeurs, et donc de maitriser les problématiques d’accès concurrent et de gestion de ressources démultipliées.

Voici la réponse de Microsoft à ces problématiques.

1. Le Dynamic Language Runtime

C# 4.0 poursuivra le travail de C# 3.0 et continuera à promouvoir l’utilisation de LINQ, afin de rendre le code plus fonctionnel et d’en faciliter la relecture., mais il fournira également de nouvelles fonctionnalités, orientées « programmation dynamique » grâce à la DLR, un socle de création de langages dynamiques implanté en surcouche de la CLR qui donnera accès aussi bien à un Object Binder .NET qu’à des Binder Silverlight, Python ou Ruby…

2. Le typage dynamique des objets

La grosse révolution de C# 4.0 est le typage dynamique d’objets. C# 4.0 introduira un type statique dynamic dont la résolution se fera non pas à la compilation, mais à l’exécution (la compilation générant en fait du script). Une vraie révolution dans le monde du .NET et une annonce très attendue par ceux qui utilisent la réflexion à outrance. L’exemple donnée est assez parlant.

Imaginez que vous ayez une méthode GetCalculator() en provenance d’une usine logicielle, qui renvoie un objet de type Object (mais dont vous savez qu’il s’agit d’un calculateur). Voici ce qu’il fallait écrire avant pour calculer 10+20 :

object calc = GetCalculator();
Type calctype = calc.gettype();
object res = calctype.InvokeMember("Add", BindingFlags.InvokeMethod, null, new object[] {10, 20});
int sum = convert.ToInt32(res).

Le code n’est pas très intuitif, et cela est principalement dû à la phase d’appel à la procédure par invocation… Voilà ce que cela pourra donner en C# 4.0 :

dynamic calc = GetCalculator();
int sum = calc.add(10,20);

3. Paramètres optionnels et nommés

C# 4.0 introduira la possibilité de définir des paramètres optionnels et nommés (oui, il aura fallu un certain temps diront les détracteurs…). Il ne sera donc plus la peine de développer 8 signatures d’une même méthode pour définir des valeurs par défaut ; autant de temps gagné par les développeurs pour s’interroger sur de vrais problèmes.

4. Améliorations relatives à l’usage de COM

Outre les paramètres optionnels et nommés déjà décrits, qui permettront d’écrire :

var maVariable = comObject.method();

au lieu de :

var maVariable = comObject.method(System.Type.Missing, System.Type.Missing, System.Type.Missing, System.Type.Missing);

C# 4.0 utilisera également ses nouvelles fonctionnalités « dynamiques » pour permettre le mapping automatique des objets (en réalité, il résoudra ce problème à l’exécution).

5. Covariance et contra-variance

Lorsque vous instanciez une classe générique avec un type référence B dérivant de A, le transtypage de B vers A des éléments de la liste était impossible. Via une astuce de déclaration de l’interface de la classe générique, cette covariance sera désormais autorisée :

IBoite<cookie> maBoiteACookies = new Boite<cookie>();
IBoite<biscuit> maBoiteABiscuits = maBoiteACookies;

Réciproquement, un second mot clé permettra des opérations de contra-variance (de la classe vers ses dérivées) et on peut dès lors imaginer des scénarios mixtes mélangeant co et contra-variance, comme l’écriture de délégués ayant des paramètres d’entrée et sortie (d’où les mots clés choisis… in et out).

6. Co-évolution des langages

Microsoft s’est engagé à faire évoluer conjointement C# et VB.NET à partir de cette version du Framework. Voilà une grande nouvelle qui devrait réjouir les développeurs VB.NET, jusque-là un peu moins bien traités que leurs camarades C#-istes.

Pour aller plus loin

Si vous désirez aller plus loin dans la compréhension des nouveautés du Framework .NET 4.0, Nexdotnet vous invite à imprimer le poster prévisionnel du Framework .NET 4.0 et à lire les articles suivants :

• [Dossier] Tour d’horizon des nouveautés de C# 4.0, par Jérôme Lambert
• [Video] The Future of C# (EN), présenté par Anders Hejlsberg
• [Video] Future Directions for Visual Basic (EN), présenté par Paul Vick et Lucian Wischik
• [Word] C# Futures, par Mads Torgersen

Article original publié sur Nexdotnet’s Blog © 2012
Sauf utilisation du droit de courte citation, cet article est soumis à la licence Creative Commons by-nd 2.0 France

MonoTouch, tel est le nom du projet, requiert un Mac et le SDK de l’iPhone pour tester les développements et les déployer sur la machine. Il permet de développer des applications en C# et VB.NET qui utilisent les API natives du bijou d’Apple après le passage du code par un compilateur statique. Ce dernier traduit le code .NET en applications natives iPhone, qui peuvent alors tourner sur la machine et même être soumises sur l’AppStore !

Evidemment, certaines contraintes imposées par Apple dans ses API limitent les possibilités de .NET. Mais les développeurs à l’origine du projet Mono font tout leur possible pour optimiser tout ça et apporter le meilleur du framework. Les Génériques sont notamment déjà de la partie.

Si tout cela vous intéresse, n’hésitez pas à visiter la page de MonoTouch ou à télécharger  la version bêta.

Article original publié sur Nexdotnet’s Blog © 2012
Sauf utilisation du droit de courte citation, cet article est soumis à la licence Creative Commons by-nd 2.0 France

Pour plus d’information, je vous invite à vous référer aux liens suivants :

- Windows PowerShell Blog

- Mastering PowerShell

Article original publié sur Nexdotnet’s Blog © 2012
Sauf utilisation du droit de courte citation, cet article est soumis à la licence Creative Commons by-nd 2.0 France

Dans un communiqué relayé par Clubic, un appel à ne pas utiliser d’application écrite en C# a été lancé dans le monde Linux. En effet, cette demande fait suite à la décision de Debian d’intégrer MONO et plus particulièrement une application C# par défaut (qui impliquerait de disposer de la plateforme pour la faire tourner).

En tant que passionné de C# et des technologies MS, cette news de Richard Stallman me peine un peu, bien que j’approuve sur le fond les raisons pour lesquelles il l’a fait.

C# : Stallman met en garde contre Microsoft

Article original publié sur Nexdotnet’s Blog © 2012
Sauf utilisation du droit de courte citation, cet article est soumis à la licence Creative Commons by-nd 2.0 France

Article original publié sur Nexdotnet’s Blog © 2012
Sauf utilisation du droit de courte citation, cet article est soumis à la licence Creative Commons by-nd 2.0 France