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 :

http://www.codeproject.com/Tips/664064/Windows-OS-Version-Detector

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

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 :

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.

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 de ce qu'est l'intégration continue.

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

Pour 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 maîtrisé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 grâce à 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éanmoins 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 enchaînement 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, oups ce n'est pas aisé d'utiliser cet outil que je trouve un peu archaïque

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.

ReSharper de JetBrains : payant

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

SVN ou Subversion

CVS

Git

Perforce 

Tests Unitaires

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

MSTest vs. NUnit with Visual Studio 2010 & TDD

NUnit vs xUnit parmi les modules de Tests Unitaires lequel choisir ?

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. Vous avez compris l'intégration continue concerne toutes les phases de développement du logiciel et l'utilisation des outils qui permettent d'automatiser tout ce qui peut l'être.

To Be Continued

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.


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 ...

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

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

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

Pour aller plus loin avec python, être au courant des dernières nouveautés en Python, je vous propose le site très bien fait et qui permet une prise en main rapide de ce langage étonnant qu'est Python, voici :

Python CheatSheet - The Zen Of  Python

Vous y trouverez une prise de main rapide de python avec VSCode et l'extension Poetry, c'est très intéressant.

Have fun!

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 :

http://www.python.org/

http://www.python.org/download/

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 :

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

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.