cogimator.net

Une ligne à la fois...

De 0 a un package Nuget

En préparant un projet de démo AngularJS + Bootrap + Web Api (article a venir !), j’ai eu besoin de générer des données de test. Après quelques recherches infructueuses, j’ai donc choisi de monter mon petit projet. Ca tombe bien, j’avais envie de coder un petit projet “utilitaire”, et de me faire plaisir avec une API de type “Fluent”.

Une première version est dores et déjà disponible sur github : https://github.com/mathieubrun/Cogimator.SampleDataGenerator. J’aurais l’occasion de vous en reparler dans un article à venir (ca commence a faire beaucoup d’articles à venir…).

Apres l’avoir référencé “manuellement” dans mon projet de démo AngularJS, je me suis demandé comment optimiser le déploiement de mon générateur de données. Ca tombe bien, j’avais envie de créer un package nuget.

 

Etape 1 : création du projet

Rien d’exceptionnel, une solution Visual Studio standard, avec l’option “Activer la restauration des packages nuget” activée, ceci afin d’avoir un nuget.exe accessible facilement en ligne de commande depuis le dossier de la solution.

Etape 2 : création d’un compte Nuget.org

Ici, toujours rien de complètement fou, on s’enregistre, et on note bien l’api Key, pour l’activer sur le poste de développement.

 

Etape 3 : création du fichier .nuspec

Ici, les choses peuvent un peu se compliquer, selon le temps que l’on souhaite consacrer à la documentation Nuget. Pour faire simple, il faut initialiser un fichier .nuspec avec la commande suivante

.nuget\nuget.exe spec

Ensuite, il faut déplacer ce fichier dans le dossier du projet qui va servir a générer le package, et lui donner le même nom que le .csproj :

image

Enfin, il ne reste plus qu’a modifier le contenu du fichier nuspec pour l’adapter a votre projet.

Etape 4 : publication manuelle

La création du package est maintenant possible, avec la commande

.nuget\nuget.exe pack Cogimator.SampleDataGenerator\Cogimator.SampleDataGenerator.csproj

Nuget s’appuiera sur les .csproj et .nuspec pour générer le package.

Il ne reste plus qu’a l’uploader sur nuget.org.

Etape 5 : le serveur d’intégration continue

J’ai choisi TeamCity pour remplir ce rôle, principalement en raison de sa simplicité, et aussi parce qu’il est développé par JetBrains (auteurs de ReSharper, donc pas vraiment des amateurs).

Je ne rentre pas dans les détails de l’installation, du type next, next, next. Comme j’exécute TeamCity sur mon poste de travail, J’ai juste changé le compte d’exécution des services pour “System account”. Sur un serveur dédié j’aurais crée un user spécifique (car c’est très mal de faire tourner des services avec System account !)

Une fois le serveur installé, il ne reste plus qu’a se rendre sur l’adresse http://localhost (avec le port spécifique si vous l’avez configuré ainsi) pour finaliser l’installation.

Ensuite, il faut créer un nouveau projet, avec un configuration associée. Ici, les valeurs par défaut feront très bien l’affaire.

Une fois le projet créer, il faut lui associer un contrôle de code source. TeamCity supporte git nativement, l’url présente sur la home de votre projet doit être reprise :

image

Petite subtilité, j’ai repris l’exécutable fourni avec le client github (dans ) et je l’ai copié dans un dossier spécifique :

image

Les étapes de build sont également aisées à configurer (je repense au temps passé a pondre du xml pour CruiseControl.NET…). La première étape est la compilation. Si vous avez bien paramétré le contrôle de code source, vous pouvez déjà choisir le fichier .sln avec le picker a droite du champ “solution file path” :

image

Nous arrivons maintenant aux étapes concernant nuget. L’ajout d’une tache “Nuget pack” vous aménera a l’écran suivant :

image

Ici, il faut bien penser à aller dans “Nuget settings” pour télécharger un client nuget pour TeamCity. Il est également possible de publier les packages nuget dans un feed local au serveur teamcity. Ce qui peut s’avérer plutôt pratique pour les développements en entreprise… Il est aussi à noter que le package sera généré avec un numéro de version correspondant par défaut au numéro de build. Ce qui s’avère pratique pour les mises à jour du package.

Enfin, la publication se fait avec la tache “Nuget publish” :

image

Une fois le build complété avec succès, on peut vérifier la présence du package sur nuget.org :

image

IIS Express Here

Parfois, pour tester rapidement un exemple d’application JS, il peut être utile de pouvoir lancer rapidement un serveur web. Entre en scene IIS Express, et sa ligne de commande… Encore mieux, un petit fichier de registre a appliquer, pour pouvoir lancer IIS Express depuis l’explorateur windows : https://github.com/chrismcabz/IIS-Express-Here. Et quand on a fini de tester, il y a juste a fermer la console ouverte… Pratique.

Utilisation mémoire d’un processus .NET

Lorsque l’on ouvre le gestionnaire des taches Windows, on peut y voir un onglet “Mémoire (jeu de travail privé)” pour chaque processus. Mais que ce cache derrière ce chiffre ? Afin de le savoir, je vais vous présenter l’outil VMMap, de Sysinternals, disponible au téléchargement ici : http://technet.microsoft.com/en-us/sysinternals/dd535533.aspx

Cet outil va vous présenter trois graphes de mémoires :

  • Commited : représente la quantité qu’occuperaient tout le code et données de l’application, ainsi que les fichiers mappés par celle ci.
  • Private Bytes : représente la quantité de mémoire demandée par le processus, et ne pouvant être partagée avec d’autres processus. Cette mémoire peut se trouver sur un fichier d'échange.
  • Working Set : représente la mémoire physique utilisée par le processus, c’est à dire qu’aucun accès au fichier d’echange ne sera fait lors d’un accès à cette mémoire.

Ces trois graphes sont subdivisés en différentes catégories. Typiquement, les catégories sur lesquelles le développeur pourra avoir un impact sont :

  • Image : représente les librairies chargées par l'application.
  • Managed Heap : représente les tas alloués par la CLR .Net. Une augmentation incontrôlée de cette valeur peut indiquer une fuite mémoire.
  • Private : représente la mémoire non allouée par la CLR .Net. Par exemple,  les données d'une image chargée au travers de Bitmap.FromFile seront dans cette zone mémoire.

Voici quatre captures d'écran de l’outil VMMap,  représentant quatre états de la mémoire pour une application simple.

Après le chargement de l'application :

image

On peut constater que la mémoire “Managed Heap” ainsi que “Private Data” sont respectivement de 2.3 et 25 Mo.

Après création de 10 tableaux de 1000000 bytes (non initialisés) :

image

La partie “Managed Heap” dans “Private Bytes” est maintenant de 109 Mo. Il s’agit uniquement de mémoire réservée, et non de mémoire utilisée ! C’est bien pour cela que le “Managed Heap” dans le “Working Set” est toujours de 2.5Mo.

Après l'initialisation de ces tableaux :

image

Cette fois ci, la taille du “Managed Heap” dans le “Working Set” a augmenté de manière significative : 108 Mo.

Après chargement de 300 images png de 40Ko.

image

Les données des images ont été allouées dans “Private data”, car System.Drawing.Bitmap utilise du code non managé.

Enfin, pour suivre la consommation mémoire d’une application, on pourra se baser sur les compteurs de performance suivants :

image

ASP.NET MVC Controls par Telerik

A la recherche d’un TreeView pour ASP.NET MVC, je suis arrivé chez Telerik ( http://www.telerik.com/products/aspnet-mvc.aspx ), qui propose une suite de contrôles (dont mon TreeView).

Les démos sont visibles ici : http://demos.telerik.com/aspnet-mvc/ et le code source est disponible en GPL sur CodePlex : http://telerikaspnetmvc.codeplex.com/.

Le Grid est particulièrement impressionnant, avec tri, pagination, filtres, et groupement (ouf, la liste est finie). Le tout avec du Linq derrière. Pour les plus gros jeux de données, tout est paramétrable.

A tester !

VS 2010 Productivity Power Tools

Disponible depuis quelques semaines, et mise à jour récemment, cette suite de “power tools” pour Visual Studio 2010 apporte son lot d’agréments :

Solution Navigator

Remplace avantageusement l’explorateur de solution pour parcourir les projets/fichiers d’une solution. En effet, ce nouvel onglet permet :

- de déplier les fichiers source, afin d’en afficher la liste des membres.
solution_explorer

- d’afficher uniquement les fichiers ouverts, ou les fichiers non sauvegardés.
solution_explorer_2

- les onglets prennent une couleur par projet, et il est possible de les épingler
solution_explorer_3

Power commands

Mon rêve, enfin exaucé : formater le document automatiquement, et trier/supprimer les using. Ceux qui utilisent régulièrement StyleCop comprendront tout l’intérêt de la chose.
solution_explorer_4

En conclusion, les fans de raccourcis claviers, et d’optimisation de leur productivité sous Visual Studio seront ravis. Le meilleur : c’est gratuit. Ceux qui n’ont pas de licence Reflector apprécieront !