jeudi 26 septembre 2013

Windows - Informations sur votre CPU

Si les informations que vous obtenez par le menu démarrer->Tous les programmes->Accessoires->Outils systèmes->Informations système ne vous suffisent pas :

Windows XP - Outils d'informations système
Alors pour obtenir des informations sur la configuration de votre CPU, il existe une fonction C++ :

BOOL WINAPI GetLogicalProcessorInformation(
  _Out_    PSYSTEM_LOGICAL_PROCESSOR_INFORMATION Buffer,
  _Inout_  PDWORD ReturnLength
);

La page de documentation de cette fonction dans le Developer Network est Ici.

La mise en oeuvre de cette fonction dans un petit utilitaire .exe (346 KB) du TechNet, vous la trouverez Ici.

C'est grâce à cet utilitaire que j'ai découvert que mon processeur était incompatible avec Windows 8 !

Vous  trouverez également sur cette page du TechNet une foule d'outils complémentaires qui permettent de gérer en profondeur votre système Windows.

Windows OS Version

Concernant la version de votre Windows j'ai découvert également cette page :

Utilitaire en Visual Basic un peu idiot mais il liste les différentes version de Windows et c'est intéressant !


mercredi 25 septembre 2013

Machines Virtuelles - Oracle Virtual Box

Lorsque l'on développe dans plusieurs environnements de développements, plusieurs plateformes Windows, Linux, plusieurs chaines de développement, Visual Studio, Eclipse, plusieurs frameworks .NET, Qt C++. C'est un plaisir et un confort sans pareil de pouvoir installer une machine propre avec juste ce qu'il faut et de ne pas surinstaller des outils sur d'autres outils, ce qui rendrait votre machine de développement instable à coup sûr.

Pour cela nous faisons appel à des machines virtuelles.

Oracle VM Virtual Box

Ayant tenté d'installer une machine virtuelle avec Virtual PC 2007 et une image ISO de Windows 8.1 sans succès, me voici en train d'installer "Oracle VM Virtual Box" sur mon Windows XP SP 3 et voici la dialog box que le programme d'installation me renvoie :

Continuer l'installation de ce logiciel peut mettre en péril ou déstabiliser le bon fonctionnement de votre système, maintenant ou dans l'avenir.
Oracle VM Virtual Box - Installation Microsoft Warning Message
Je me permets de prendre note ici de cette erreur d'installation car c'est la première fois que je vois une telle erreur d'installation, une mise en garde où l'on a l'impression que tout va sauter !

Détails de l'erreur :

Continuer l'installation de ce logiciel peut mettre en péril ou déstabiliser le bon fonctionnement de votre système, maintenant ou dans l'avenir. Microsoft recommande fortement que vous arrêtiez cette installation maintenant et contactiez le fournisseur du logiciel pour obtenir le logiciel qui a été validé lors du test permettant d'obtenir le logo Windows.

Solution

Cliquez sur "Continuer", mais Oui ! Alors il est vrai qu'Oracle VM Virtual Box installe nombre de logiciels en stoppant votre Network (réseau) puis en le redémarrant et que vous devrez cliquez environ une dizaine de fois sur "Continuer" mais il fini par s'installer.





vendredi 28 juin 2013

Outils d'intégration continue

Quand on a pratiqué l'intégration continue entièrement intégrée avec Team Foundation Server, on est un peu désarçonné par l'ensemble de tous les outils qui peuvent être utilisés afin de mettre en place une stratégie d'intégration continue avec d'autres chaînes de développement que TFS. Cet article est là pour faire un petit récapitulatif.
Team Foundation Server
Les principes d'intégration continue permettent de distinguer un développement artisanal d'un développement  industriel ou développement maîtrisé de façon professionnelle.

En intégration continue, vous avez forcément un serveur dédiée sur lequel le produit logiciel est déployé afin de faire une vérification complète du produit avant de déployer sur une cible finale, ce n'est pas le cas dans le cadre d'un développement artisanal.

Les Principes de l'Intégration Continue

  • le code source est partagé et versionné dans un gestionnaire de code source (un référentiel ou repository unique)
  • les développeurs intègrent (commit ou checkin) leur code le plus souvent possible (chaque jour par exemple)
  • des tests unitaires sont développés et des tests d'intégration permettent de valider l'application sur un serveur d'intégration (ou serveur de build)
La mise en place de ces principes permet de :
  • tester immédiatement les unités modifiées et leur compatibilité entre elles
  • découvrir immédiatement des codes manquants ou incompatibles
  • les problèmes d'intégration sont réparés pour éviter les problèmes de dernière minute
  • une version est toujours disponible pour un test une démonstration ou une distribution
Qu'est ce que l'intégration continue sur le site de So@t
Intégration continue des bases de données : RedGate avec SQL Toolbelt comparaison de schémas de base de données. BD SQL Server ou Oracle.
Team Foundation Server pour :
Gestion de Projet
Gestion de prérequis
Versionnement de code source
Gestion de cas de test
Automatisation de build
Génération de rapports
Configuration du serveur TFS : Team Server Foundation en pas à pas

Sur le Blog de Julien Carnelos : L'intégration continue Open Source en .NET
Principe : Tout ce qui peut-être automatisé doit l'être.
Contrôle de codes sources : SVN (Subversion)
Tests Unitaires : NUnit
Compilation et Build : NAnt
Contrôle de construction : CruiseControl.NET et CCTray
Aller plus loin : Mise en place d'outils d'analyse de codes sources de génération de métriques. Terminer le Build NAnt par la génération d'un package d'installation prêt pour la livraison. L’envoi d'un email de notification à un client ou mieux à une équipe de QA (Assurance Qualité).

Je me propose de recopier ici quelques bonnes phrases du blog de J.Carnelos car les liens cassent ...

On oppose généralement l’aspect industriel du développement à l’artisanal. Pour mieux saisir la signification de ce terme, je vous propose une petite histoire :

Après quatre mois de développement, c’est le grand jour de la livraison. Georges, après avoir testé une dernière fois que son code compile, décide de déployer la version finale du site Intranet de la mairie. La démarche est maitrisée puisque cela fait maintenant une vingtaine de fois qu’il a répété l’opération. Comme à chaque fois, il commence par demander à son collègue sur quels fichiers il a travaillé. La liste connue, il récupère par le réseau ces fichiers, puis tente de compiler le projet. Chance, tout compile.

La suite est plus délicate, Georges doit se connecter à distance au serveur, migrer la base de données et insérer les données mis à jour. Vient ensuite la partie copie des fichiers sur le serveur et redémarrage du serveur. A ce moment, si tout va bien, le site devrait être mis à jour. Malheureusement, au premier test, impossible de se logger.

Si cette scène vous rappelle quelque chose, pas d’inquiétude car c’est courant et aujourd’hui de nombreuses sociétés fonctionnent dans ce mode de gestion. Mais l’industrialisation et l’automatisation sont maintenant un but plus facile que jamais à atteindre grace à de nombreux outils. Preuve en est également l’implication de Microsoft sur le thème « Gestion du cycle de vie logiciel » et la fourniture d’une offre complète avec la suite Team System et son serveur Team Foundation Server.

Néamoins pour des raisons de simplicité, nous nous attacherons ici à présenter les concepts de l’intégration continue à l’aide uniquement d’outils open-source.

Concept

Schéma d'une chaine d'intégration continue
L’intégration continue est un concept qui se base sur l’analogie avec une usine automatisée. Sauf qu’au lieu de construire des voitures, on construit un logiciel. Cette « usine » est construite sur l’enchainement suivant :
  1. Un développeur travaille en local. Lorsque ses modifications sont terminées, il archive son code sur un serveur gestionnaire de sources.
  2. A la détection d’un changement (ou suivant une règle temporelle paramétrée), le serveur d’intégration récupère la dernière version des sources et déclenche la construction (« build ») de la solution.
  3. En étape facultative mais intéressante, il est possible d’appliquer des métriques et des tests sur la solution et d’en générer des rapports
  4. Enfin, la solution et le bilan de la construction sont déployés sur un serveur de résultat accessible à l’équipe projet. Dans le cas d’un sous traitance, ce portail peut aussi être mis à la disposition du client pour qu’il puisse constater l’avancement du projet. (Particulièrement utile dans le cadre d’une démarche agile).

Documentation des codes sources

On ne crée pas de bons codes sources sans bonne documentation.
NDoc : Open Source Documenter, Générateur de documentation pour .NET

Sous TFS : SharePoint

Outils d'analyse des codes sources

Fédérer une équipe autour d'un développement passe par le partage d'un certain nombre de bonnes pratiques, on appelait cela les coding guidelines aujourd'hui des outils permettent d'automatiser cette tâche en analysant les codes sources.

StyleCop : analyse syntaxique du code source C# sur le CodePlex : StyleCop
StyleCop provides value by enforcing a common set of style rules for C# code.


Un outil d'analyse de code dans Visual Studio Express 2012

FxCop : curieux on note Framework 2.0, semble ne plus exister

Contrôle de codes sources, gestionnaire de versions

C'est un serveur, un endroit centralisé pour récupérer les codes sources créés par les développeurs, un outil permettant de versionner. Permet de résoudre les conflits de réaliser un merge entre plusieurs développements.

Outils :
TFS
CVS
Git
Perforce 

Tests Unitaires

Il existe MSTest mais il semble que cet outils de tests unitaires soit maintenant supplanté par NUnit ...

Sur la plateforme .NET : NUnit
Sur le site du code project, rapidement comprendre NUnit : Unit Testing Using NUnit
NUnit permet d'écrire des tests unitaires du genre :
Assert.AreEqual(expected, actual)
NUnit permet l'utilisation de Mock Objects (simulateur d'objets)
A priori le projet NUnit n'est plus hébergé sur source forge mais Ici

Serveur d'intégration ou serveur de builds

C'est un élément clef de l'intégration continue souvent manquant dans les organisation "amateurs".

Les opérations à effectuer grâce aux outils de builds sont :
Nettoyer le répertoire de sortie (les binaires)
Compiler le code source
Exécuter les tests unitaires
Exécuter le programme

Mais aussi :
zip de fichier
transfert ftp
redémarrage de serveur web
En partant des sources, effectuer toute la livraison jusqu’à l’étape déployable (ou même déployé).

Intégration continue avec Team Foundation Server
MSBuild
NAnt qui possède l'avantage d'être multi-plateforme, s'exécute en ligne de commande et prend en paramètre un fichier XML qui décrit les différentes étapes pour emmener le code source dans l'état prêt à l'exécution.

CruiseControl.NET

TeamCity : de JetBrains
For .NET :
Building Visual Studio solutions; native support for MSBuild, Powershell or NAnt
Code analysis for C#, VB.NET, XAML, and many other languages powered by ReSharper
Testing with .NET testing frameworks, including: NUnit, MSTest, MSpec, xUnit and all Gallio-based frameworks
Code coverage with dotCover, NCover or PartCover
Best-in-class NuGet support

Je compléterai plus tard ... vous avez des suggestions d'amélioration et de complétion de cet article, n'hésitez pas à le commenter.

To Be Continued

jeudi 27 juin 2013

Outils pour scanner les espaces de vos disques durs

Vous cherchez un outils qui vous donne une représentation rapide de l'encombrement de vos disques durs afin de trouver de la place ou d'y faire le ménage.

Je fais ici référence à un outil super pratique pour scanner l'espace de vos disques durs et se rendre compte de ce qui prend de la place. Je l'ai écris dans le blog de l'admin windows parce qu'il sert essentiellement à l'admin pour gérer les espaces des disques durs.

http://www.steffengerlach.de/freeware/
La dernière fois que je cherché un tel outil, je ne suis tombé que sur des daubes, alors le voici :

https://administration-windows.blogspot.fr/2015/06/freeware-utilitaire-de-gestion-de.html

Je vous redirige vers le Blog de l'Administrateur Windows ...


mercredi 26 juin 2013

Moteur de Build Microsoft : MSBuild Engine (4)

Je souhaite réaliser la programmation d'une Tâche MSBuild. En lisant MSDN, il est parfois difficile de passer de la théorie à la pratique. Ici on va donc être pratique et réussir la programmation et l'exécution d'une tâche MSBuild.

Programmation d'une tâche MSBuild

On a vu dans MSBuild Engine (1) que l'on doit utiliser les directives using :
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;

Ces DLL se trouvent dans :
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319


En ajoutant dans le projet leurs références, un petit souci survient, des icônes en jaune :

Using MSBuild in .NET Framework 4.0 Client Profile
Afin d'utiliser ces deux DLL, il faut configurer le .NET Framework 4.0 dans les propriétés du projet :

Using MSBuild in .NET Framework 4.0
Choisissant le .NET Framework 4, le problème est résolut :

Using MSBuild choix du .NET Framework 4.0
L'utilisation de ces librairies n'est bien entendu pas comprise dans le "Client Profile". Il n'y a aucune raison d'exécuter une build sur un client.

Je peux maintenant ajouter une Class dans mon projet MyBuildProject :

using System;
using Microsoft.Build.Utilities;

namespace MyBuildProject
{
    public class TaskMSBuild : Task
    {
        public override bool Execute()
        {
            Console.WriteLine("TaskMSBuild Executed ...");
            return true;
        }
    }
}

Dans le .csproj, je rajoute :

<UsingTask TaskName="TaskMSBuild" 
             AssemblyFile="E:\WPF Presentation Sample\MyBuildProject\MyBuildProject\bin\Debug\MyBuildProject.exe" 
             TaskFactory="ClassName" />

  <Target Name="MyTargetTaskMSBuild">
      <TaskMSBuild />
  </Target>

Etant donné que ma tâche est directement dans mon projet j'ai donc la propriéte "AssemblyFile" settée avec mon .exe. Le tag "<TaskMSBuild />" semble ne pas trop être apprécié par l'interpréteur ...

J'ai comme l'impression que cela ne va pas fonctionner :
Programmation d'une Tâche MSBuild dans la fenêtre console commande de Visual Studio
Il y a plein de rouge ! Heureusement MSBuild est là pour m'aider et corriger mes erreurs.

Exécution d'une tâche MSBuild réussie

Finalement dans mon fichier projet, je garde :

  <UsingTask TaskName="TaskMSBuild" 
             AssemblyFile="E:\WPF Presentation Sample\MyBuildProject\MyBuildProject\bin\Debug\MyBuildProject.exe" />

  <Target Name="MyTargetTaskMSBuild">
    <TaskMSBuild />
  </Target>

Et à l'exécution :

Programmation d'une Tâche MSBuild exécution réussie
J'ai bien une trace de l'exécution de ma tâche MSBuild : "TaskMSBuild Executed ...".

Download Sample Code

Requirements :
Visual Studio 2010


mardi 25 juin 2013

Moteur de Build Microsoft : MSBuild Engine (3)

Voyons un peu comment, à l'aide de Visual Studio et dans les propriétés du projet (.csproj) je peux insérer des événements. Et observons les impacts que cela à dans mon fichier projet le tout par rapport à la syntaxe MSBuild.

Pré-Build  et Post-Build Events

Je vais créer deux commande DisplayPreBuildEvent.cmd et DisplayPostBuildEvent.cmd que je vais déclencher dans les propriétés de mon projet :

DisplayPreBuildEvent.cmd
@echo OFF
echo ----------------------
echo ------ Pre BUILD Event
echo ----------------------
@echo ON

J'ouvre donc les propriétés de mon projet, bouton-droit, "Properties" :

MSBuild - Propriétés du projet
Dans l'onglet "Build Events" je colle le CALL aux deux commandes :
MSBuild - Build Events Call Commandes
J'appelle maintenant MSBuild depuis la console de commande Visual Studio, voici l'exécution que j'obtiens :
MSBuild - Exécution des Pré et Post Build Events
Mes deux commandes s'affichent bien. Ayant conservé la substitution des cibles MSBuild, je peux voir comment l'exécution de ces commandes s'insèrent dans le processus de génération.

Syntaxe MSBuild : Pré-build et Post-Build Events

Que s'est-il passé au niveau de mon fichier projet (.csproj) ?
En l'ouvrant, je constate l'insertion des deux lignes d'appelle à mes commande de post et de pré-build :

<PropertyGroup>
<PreBuildEvent>call "...\MyBuildProject\DisplayPreBuildEvent.cmd"</PreBuildEvent>
</PropertyGroup>
<PropertyGroup>
<PostBuildEvent>call "...\MyBuildProject\DisplayPostBuildEvent.cmd"</PostBuildEvent>
</PropertyGroup>

Voilà donc la syntaxe MSBuild de mon action effectuée dans Visual Studio.


Moteur de Build Microsoft : MSBuild Engine (2)

Allons un peu plus loin dans le langage MSBuild.

Précédemment dans ce blog

Modification du fichier projet .csproj

Lors de la création d'un projet avec Visual Studio effectivement pour pouvoir éditer le .csproj il faut décharger le projet ensuite avec bouton-droit sur le projet décharger vous pouvez choisir "Editer le fichier .csproj".

En bas de ce fichier, vous trouvez le début de la personnalisation du processe de Build et le code suivant :

<!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
      Other similar extension points exist, see Microsoft.Common.targets.
<Target Name="BeforeBuild">
</Target>
<Target Name="AfterBuild">
</Target>
-->

Pour utiliser ce code, il suffit de le décommenter.

Customisation de Visual Studio pour MSBuild

Pour travailler plus efficacement car il va me falloir décharcher et recharger sans cesse le projet MyBuildProject.csproj afin de le modifier. J'ai envie de me créer une barre de boutons perso avec les deux boutons "Unload Project" et "Relaod Project".

J'obtiens la barre suivante :

Visual Studio - MyCustomBar avec les boutons "Unload" et "Relaod"

Exécution d'une Target (cible) spécifique de Build

En ajoutant les lignes suivantes dans mon fichier .csproj :

  <Target Name="HelloWorld">
    <Message Text="Hello"></Message>
    <Message Text="World"></Message>
  </Target>

J'ai ajouter une cible spécifique nommée "HelloWorld". Pour l'exécuter, j'ouvre la console commande de Visual Studio :

Exécution de MSBuild dans la console Visual Studio
Vous obtenez le résultat de l'exécution de la commande MSBuild :

>msbuild myProject.csproj /t:HelloWorld

Résultat de l'exécution de MSBuild dans la console Visual Studio
Les lignes :

Hello
World

apparaissent dans la console.

Remarque : l'exécution de MSBuild dans la console Visual Studio est plus verbose (plus parlante) que dans Visual Studio où l'on obtient le résultat suivant :

------ Build started: Project: MyBuildProject, Configuration: Debug x86 ------
  MyBuildProject -> E:\WPF Presentation Sample\MyBuildProject\MyBuildProject\bin\Debug\MyBuildProject.exe
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

Je n'ai donc exécuté que la target spécifique "HelloWorld" grâce au commutateur /t

Substitution et exécution des cibles MSBuild

J'ajoute maintenant les lignes suivantes dans mon fichier .csproj :

  <Target Name="BeforeBuild">
    <Message Text="Message BeforeBuild"></Message>
  </Target>
  <Target Name="AfterBuild">
    <Message Text="Message AfterBuild"></Message>
  </Target>

Et je j'exécute la commande :

>msbuild

Remarque : Que l'on ajoute ou non le nom du fichier .csproj, le résultat de la commande est le même. En fait si un seul fichier .csproj existe dans le répertoire alors MSBuild le prend par défaut et s'il y a plusieurs fichiers .csproj dans le répertoire alors MSBuild sort en erreur :

MSBuild - Exécution de la commande >msbuild dans la console de commande Visual Studio
J'obtiens bien mes deux messages :

Message BeforeBuild
Message AfterBuild

En suite, je vous propose de lire une page sur le site MSDN :
Comment : étendre le processus de génération Visual Studio

On y croisera l'ensemble des cibles que l'on peut substituer sans risque.

Subsitution de toutes les cibles MSBuild

Voici donc l'ensemble des cibles que l'on peut substituer sans risque :

BeforeCompile, AfterCompile
Les tâches insérées dans l'une de ces cibles s'exécutent avant ou après que la compilation principale a eu lieu. La plupart des personnalisations sont faites dans l'une de ces deux cibles.
BeforeBuild, AfterBuild
Les tâches insérées dans l'une de ces cibles s'exécutent avant ou après toutes les autres tâches de la génération.
Remarque : Les cibles BeforeBuild et AfterBuild sont déjà définies dans les commentaires à la fin de la plupart des fichiers projet. Vous pouvez ainsi ajouter facilement des événements avant génération et après génération à votre fichier projet.
BeforeRebuild, AfterRebuild
Les tâches insérées dans l'une de ces cibles s'exécutent avant ou après l'appel de la fonctionnalité de régénération principale. L'ordre de l'exécution cible dans Microsoft.Common.targets est le suivant : BeforeRebuild, Clean, Build, puis AfterRebuild.
BeforeClean, AfterClean
Les tâches insérées dans l'une de ces cibles s'exécutent avant ou après l'appel de la fonctionnalité de nettoyage principale.
BeforePublish, AfterPublish
Les tâches insérées dans l'une de ces cibles s'exécutent avant ou après l'appel de la fonctionnalité d'édition principale.
BeforeResolveReference, AfterResolveReferences
Les tâches insérées dans l'une de ces cibles s'exécutent avant ou après la résolution des références d'assembly.
BeforeResGen, AfterResGen
Les tâches insérées dans l'une de ces cibles s'exécutent avant ou après la génération des ressources.

L'ensemble des cibles substituables se trouve dans les fichiers :
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets

Erreur de la documentation :
En ouvrant le fichier Microsoft.Common.targets du Framework 4.0, on s'aperçoit qu'il y a une erreur dans la documentation : BeforeResolveReference s'écrit comme AfterResolveReferences avec un "s".

Par curiosité j'ai créé un fichier .csproj avec l'ensemble de ces cibles, j'obtiens l'exécution de MSBuild suivante :
MSBuild - Exécution de toutes les cibles substituables
On s'aperçoit que dans ce cas, elles ne sont pas toutes exécutées et l'on découvre l'ordre d'exécution logique des cibles de MSBuild.






Moteur de Build Microsoft : MSBuild Engine (1)

MSBuild, est un outil de génération d'applications. Il utilise un schéma XML pour contrôler la génération de produits logiciels. Visual Studio utilise MSBuild mais MSBuild ne dépend pas de Visual Studio.

En appelant MSBuild sur un fichier projet ou solution, vous pouvez orchestrer ou générer des produits dans des environnements où Visual Studio n'est pas installé.

Dans les fichiers projets (.csproj) vous trouverez le code XML MSBuild qui s'exécute lorsque l'on génère l'application.

Ainsi vous pouvez modifier le système de génération et :
  • Prétraitez les fichiers avant qu'ils atteignent le compilateur.
  • Copiez les sorties de génération vers un autre emplacement.
  • Créez les fichiers compressés les sorties de génération.
  • Effectuez une étape de post-traitement. Par exemple, vous pouvez emboutir un assembly avec une version différente.
Exemple d'utilisation : Utiliser Visual Studio sur un ordinateur de développement pour écrire le code XML de MSBuild  à l'aide de l'IDE, puis transmettre ce code aux autres développeurs qui l'exécuteront en ligne de commande afin d'intégrer votre développement.

MSBuild est utilisé dans le cadre d'une stratégie d'intégration continue.

On trouve MSBuild.exe dans les répertoires :
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
C:\WINDOWS\Microsoft.NET\Framework\v3.5

Egalement avec l'installation du Framework 4.5

Allez plus loin Ici.

Procédure pas à pas d'utilisation de MSBuild

Création d'un projet MSBuild et examen du fichier projet

Vous créez un projet avec Visual Studio, en suite pour éditer le fichier .csproj vous devez "Décharger  le projet" puis en cliquant bouton droit vous pourrez éditer, modifier le fichier .csproj.

Les fichiers XML MSBuild ont un noeud racine : "Project"
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build"  xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

Notion de Tâche MSBuild

Une tâche est la plus petite unité de travaille (l'atome) d'une build.

Les tâches MSBuild fournissent du code exécuter pendant le processus de génération. Chaque tâche est implémentée dans une classe .NET qui dérive de l'interface ITask.

Une bibliothèque de tâches courantes est fournit avec MSBuild mais pour écrire vos propre tâche il y a deux approches :
  • Implémentez l'interface ITask directement.
  • Dérivez votre classe de la classe d'assistance, Task, qui est définie dans l'assembly Microsoft.Build.Utilities.dll. La tâche implémente ITask et fournit des implémentations par défaut de quelques membres ITask. En outre, la journalisation est plus facile.
Exemple code C# :

using System;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;

namespace MyTasks
{
    public class SimpleTask : Task
    {
        public override bool Execute()
        {
            return true;
        }
    }
}

Le fichier projet qui exécute cette tâche :

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Target Name="MyTarget">
        <SimpleTask />
    </Target>
</Project>

Allez plus loin Ici

Pour exécuter une tâche, MSBuild a besoin de mapper la tâche sur l'assembly qui contient son implémentation à l'aide de UsingTask.

<UsingTask TaskName="TaskName"
    AssemblyName = "AssemblyName" 
    TaskFactory = "ClassName"
    Condition="'String A'=='String B'" />

Notion de Cible MSBuild

Une cible est une séquence nommée de tâches.

Déclaration des cibles dans le fichier projet

<Target Name="Construct">
    <Csc Sources="@(Compile)" />
</Target>

Cibles prédéfinies :

<Target Name="AfterBuild" >
   <Message Text="First occurrence" />
</Target>
<Target Name="AfterBuild" >
   <Message Text="Second occurrence" /> 
</Target>


Dans ce cas uniquement la "Second Occurence" sera exécutée car MSBuild n'exécute qu'une fois une cible unique.

Ordre de génération des cibles

  • Cibles initiales
  • Cibles par défaut
  • Première cible
  • Dépendances cible
  • BeforeTargets et AfterTargets (MSBuild 4.0)
Allez plus loin Ici.

Traitement par lots des cibles

Une cible peut avoir un attribut Outputs qui spécifie des métadonnées, dans ce cas, MSBuild exécute la cible une fois pour chaque valeur de métadonnées unique, en regroupant ou en "traitant par lot".
Exemple :

<ItemGroup>
    <Reference Include="System.Core">
      <RequiredTargetFramework>3.5</RequiredTargetFramework>
    </Reference>
    <Reference Include="System.Xml.Linq">
      <RequiredTargetFramework>3.5</RequiredTargetFramework>
    </Reference>
    <Reference Include="Microsoft.CSharp">
      <RequiredTargetFramework>4.0</RequiredTargetFramework>
    </Reference>
</ItemGroup>
<Target Name="AfterBuild"
    Outputs="%(Reference.RequiredTargetFramework)">
    <Message Text="Reference:
      @(Reference->'%(RequiredTargetFramework)')" />
</Target>

Donne à l'exécution :

   Reference: 3.5;3.5
   Reference: 4.0

Builds incrémentielles

Pour améliorer la vitesse de génération MSBuild utilise un mécanisme de build incrémentielle pour n'exécuter que les mises à jour. Un élément est considéré comme à jour si son fichier de sortie a la même ancienneté ou est plus ancien que son ou ses fichier(s) d'entrée.

Allez plus loin Ici.

Génération de la cible

On exécute MSBuild dans l'invite de commande de Visual Studio :

Dans le fichier myProject.csproj :

<Target Name="HelloWorld">
  <Message Text="Hello"></Message>
  <Message Text="World"></Message>
</Target>

En ligne de commande :

>msbuild myProject.csproj /t:HelloWorld

L'exécution avec le commutateur /t trouve la cible HelloWord et l'exéctute en sortie dans la fenêtre de commande on obtient :
Hello
World

Allez plus loin Ici.

MSBuild autres caractéristiques

Création de Tâches Inline Ici.

Quelques limitations de MSBuild

optimisé et facile d'utilisation qu'en association avec Visual Studio.
manuellement pénible et long d'écriture fichier dû au temps d'apprentissage de la syntaxe ...
les paramètres sont tous globaux.
plusieurs possibilités de référencer un item ou la valeur d'une propriété
la qualité de la documentation (semble s'être améliorée ...)

On parle de Ant ou NAnt également de GNU Make.

Nouveauté de la version MSBuild 4.5

Vous pouvez spécifier qu'une tâche s'exécute "out-of process" pour cibler un autre framework.net.
Vous pouvez générer des binaires qui ciblent un processeur ARM.
L'attribut d' ToolsVersion pour déterminer la version de l'ensemble d'outils MSBuild.

Nouveaux éléments du langage :
VisualStudioVersion
DoesTaskHostExist
Item
   KeepMetadata
   RemoveMetadata
   KeepDuplicates
ContinueOnError
   <Delete Files="@(Files)" ContinueOnError="WarnAndContinue"/>
   WarnAndContinue
   ErrorAndContinue
   ErrorAndStop

lundi 24 juin 2013

Langage Python - Tutoriaux

Un fois mon Python 3.3 shell d'installé, j'aimerais aller très vite, plus loin.

L'éditeur IDLE de fichiers .py

Dans la fenêtre Shell, si je déplace mon curseur vers des lignes déjà écrites et que je tape sur "Return" ou "Enter", je rappelle ce bloc de code dans le shell.

Sur le site de tutoriaux Python

http://docs.python.org/3/tutorial/controlflow.html

Je remarque une flèche en haut à droite de chaque boite de code :
Tutoriaux Python - Cacher le prompt et les sorties
Ainsi, je peux copier l'exemple de code suivant :
Tutoriaux Python - Copier-Coller directement
Directement dans la fenêtre Python Shell :

Tutoriaux Python - Exemple de code dans la fenêtre de Shell
On note au passage la jolie coloration syntaxique.

Pour exécuter ce code, Python interprète ce code bloc par bloc il faut donc copier-coller le premier bloc de code :
words = ['cat', 'window', 'defenestrate']

Puis le second :
for w in words:
    print(w, len(w))

Notez également le curseur, tapez deux "return" et après quelques essais, vous obtenez l'exécution de ce bout de code :
Tutoriaux Python - Exécution d'un exemple de deux blocs de code



Langage Python - Installation sous Windows XP

Langage multi-paradigme et multi-plateforme dont Guido van Rossum est le créateur.

Caractéristiques du langage Python :
- ramasse-miettes
- typage dynamique fort
- système de gestion des exceptions

Ce langage est influencé par les langages : ABC, C, Eiffel, ICON, Modula-3, Perl, Smalltalk, Tcl

Site dédié au langage Python :

Python 3.3.2 Windows x86 MSI Installer (Windows binary -- does not include source)
19,3 Mo (20 238 336 octets)

Installation de Python sous Windows XP

Double clique sur python-3.3.2.msi :

Python - Ecran d'installation

Python - Ecran d'installation 2

Python - Ecran d'installation - Fin
Ce que j'ai une fois Python installé sur mon système :
Python sous Windows XP
Je clique sur IDLE (Python GUI) :
IDLE Python GUI Shell
Python (command line) :
Python command line
Ces deux outils se ressemblent beaucoup, on notera dans l'IDLE GUI des menus supplémentaires.

Prochain pas :

Mon premier programme Python

Python 3.3.2 Shell -> Open File ... Python's files : *.py or *.pyw

Je créé un répertoire \\Python33\MyPython
Je créé un fichier dans ce répertoire : fibo.py 
J'ouvre ce fichier dans l'IDLE et j'écris ces quelques lignes python :

Mon premier programme Python
Je vois apparaître un menu "Run" dans ce menu une option "Run Module F5"

Python - Run F5
En cliquant sur F5, mon programme python s'exécute dans la fenêtre shell :

Python - Exécution de mon premier programme : fibo.py
Voilà, après l'exécution de mon premier programme python, je peux maintenant aller plus loin ...

Langage Python - Découverte

Vous souhaitez apprendre à programmer en Python, je vous recommande la lecture de la page suivante sur le site de developpez.com
Python est un langage multi-paradigme et multi-plateforme dont Guido van Rossum est le créateur.

Qu'allons nous en retenir ?

Python est un langage de programmation avec de très très nombreuses qualités que peu de langages fournissent. Une syntaxe très simple avec des types de données évolués qui conduit à l'écriture de programmes très compacts et très lisible.

C'est un langage, moderne orienté objet avec des concepts comme l'héritage multiple et la surcharge d'opérateurs. C'est un langage orthogonal qui avec un petit nombre de concepts permet d'engendrer des constructions très riches.

C'est gratuit !

C'est portable sur Windows, Linux, Mac OS, ...

Autrement dit vous investissez dans l'écriture de programmes que vous pouvez installer rapidement sur toutes les plateformes.

Donc plutôt que d'apprendre des langages de scripts spécifiques à chacune des plateformes il vous suffit d'installer Python et vous pouvez exécuter vos scripts.

L'installation est simple, rapide sans interactions avec le système.