Paul Musso & le .Net

Astuce du jour : Copier un fichier avec la classe Stream

2009-01-27T13:16:00.003+01:00

Voici une petite méthode qui permet de copier un fichier dans un nouveau à l'aide de la classe Stream :

public static void CopierFichier(string pNomFichier1, string pNomFichier2)

    // Initialisation des flux

    Stream streamFichier1 = new StreamReader(pNomFichier1).BaseStream ;

    Stream streamFichier2 = new FileStream(pNomFichier2, FileMode.Create, FileAccess.Write);

    // Initialisation du buffer à 32 Ko

    int taille = 1024 * 32;

    Byte[] buffer = new Byte[taille];

    int bytesRead = 0;

    // Copie du flux 1 vers le flux 2

do

        bytesRead = streamFichier1.Read(buffer, 0, taille);

        streamFichier2.Write(buffer, 0, bytesRead);

    while (bytesRead > 0);

    // Fermeture des flux

    streamFichier1.Close();

    streamFichier2.Close();

L'argument pNomFichier1 correspond au nom du fichier à copier et le 2ème correspond au nom du fichier créé par la fonction.

Entity Framework et les types complexes

2009-01-26T16:51:00.005+01:00

Les types complexes font parti des fonctionnalités manquantes de l'éditeur de modèle EDM fourni avec Visual Studio 2008. Pour pouvoir en bénéficier, il est nécessaire de modifier les fichiers CSDL (schéma conceptuel) et MSL (schéma de liaison) ainsi que de modifier les classes d'entité.

Tout d'abord à quoi sert un type complexe ? Dans une entité, il peut être utile de séparer dans un nouveau type plusieurs variables cohérentes entre elles. Par exemple, la classe Client est composée des variables suivantes :

Prenom

Telephone

Pays

CodePostal

Ville

Les 4 dernières variables sont en relation avec l'adresse du client. Il serait donc logique de les déplacer dans une classe appelée Adresse, d'où l'utilité du type complexe.

Dans Entity Framework, un type complexe ne contient aucun identifiant et il est forcément relié à une entité mère, Client pour notre exemple. Comme avec l'héritage "1 table -> plusieurs entités", c'est une autre manière de définir plusieurs entités pour une seule table.

Si vous souhaitez mettre en place un type complexe, vous serez obligé d'utiliser directement les fichiers CSDL, MSL et SSDL. L'éditeur de modèle EDM cache ses 3 fichiers dans l'assemblage du projet en tant que ressources embarquées. Pour les extraire, j'ai utilisé Reflector et l'addin FileDisassembler permettant d'extraire tous les fichiers composant un assemblage.

Une autre solution est de passer par l'utilitaire "EdmGen.exe" qui permet de générer les fichiers CSDL, MSL, SSDL. Cependant, vous perdez tout le bénéfice de définir graphiquement votre modèle via l'éditeur d'EDM (une erreur de frappe est vite arrivé dans un fichier XML …).

Pour l'exemple, je pars de la base de données utilisée dans mon article publié sur developpez.com. Vous trouverez les scripts SQL Serveur 2005 de la base dans l'archive, à la fin de ce billet.

En 1er lieu, voici le schéma logique (SSDL) :

<Schema Namespace="helloentityfxModel.Store" Alias="Self" Provider="System.Data.SqlClient" ProviderManifestToken="2005" xmlns:store="http://schemas.microsoft.com/ado/2007/12/edm/EntityStoreSchemaGenerator" xmlns="http://schemas.microsoft.com/ado/2006/04/edm/ssdl">

  <EntityContainer Name="CustomModelStoreContainer">

    <EntitySet Name="Client" EntityType="helloentityfxModel.Store.Client" store:Type="Tables" Schema="dbo" />

  </EntityContainer>

  <EntityType Name="Client">

    <Key>

      <PropertyRef Name="Id" />

    </Key>

    <Property Name="Id" Type="int" Nullable="false" StoreGeneratedPattern="Identity" />

    <Property Name="Nom" Type="varchar" MaxLength="50" />

    <Property Name="Prenom" Type="varchar" MaxLength="50" /&gt

    <Property Name="Pays" Type="varchar" MaxLength="50" />

    <Property Name="Rue" Type="varchar" MaxLength="100" />

    <Property Name="CodePostal" Type="char" MaxLength="5" />

    <Property Name="Telephone" Type="char" MaxLength="10" />

    <Property Name="Ville" Type="varchar" MaxLength="50" />

  </EntityType>

</Schema>

Pour ce fichier, rien de spécial à signaler si ce n'est la description de la table et des propriétés (colonnes) qui la composent. Aucune référence au type complexe n'apparait. Ceci est tout à fait normal puisque c'est le schéma logique faisant référence à la structure de la base de données.

Passons maintenant au schéma conceptuel (CSDL) :

<Schema Namespace="CustomModel" Alias="Self" xmlns="http://schemas.microsoft.com/ado/2006/04/edm">

  <EntityContainer Name="Context">

    <EntitySet Name="Client" EntityType="CustomModel.Client" />

  </EntityContainer>

  <EntityType Name="Client">

    <Key>

      <PropertyRef Name="Id" />

    </Key>

    <Property Name="Id" Type="Int32" Nullable="false" />

    <Property Name="Nom" Type="String" MaxLength="50" Unicode="false" FixedLength="false" />

    <Property Name="Prenom" Type="String" MaxLength="50" Unicode="false" FixedLength="false" />

    <Property Name="Telephone" Type="String" MaxLength="10" Unicode="false" FixedLength="true" />

    <Property Name="Adresse" Type="Self.Adresse" Nullable="false" />

  </EntityType>

  <ComplexType Name="Adresse">

    <Property Name="Pays" Type="String" MaxLength="50" Unicode="false" FixedLength="false" />

    <Property Name="Rue" Type="String" MaxLength="100" Unicode="false" FixedLength="false" />

    <Property Name="CodePostal" Type="String" MaxLength="5" Unicode="false" FixedLength="true" />

    <Property Name="Ville" Type="String" MaxLength="50" Unicode="false" FixedLength="false" />

  </ComplexType>

</Schema>

Il comporte la définition de l'entité Client comprenant entre autre une propriété Adresse faisant référence au type complexe CustomModel.Adresse. Celui-ci est composé de 4 propriétés (Pays, Rue, CodePostal, Ville).

Pour finir, voici le schéma de liaison (MSL) :

<Mapping Space="C-S" xmlns="urn:schemas-microsoft-com:windows:storage:mapping:CS">

  <EntityContainerMapping StorageEntityContainer="CustomModelStoreContainer" CdmEntityContainer="Context">

    <EntitySetMapping Name="Client">

      <EntityTypeMapping TypeName="CustomModel.Client">

        <MappingFragment StoreEntitySet="Client">

          <ScalarProperty Name="Id" ColumnName="Id" />

          <ScalarProperty Name="Nom" ColumnName="Nom" />

          <ScalarProperty Name="Prenom" ColumnName="Prenom" />

          <ScalarProperty Name="Telephone" ColumnName="Telephone" />

          <ComplexProperty Name="Adresse" TypeName="CustomModel.Adresse">

            <ScalarProperty Name="Pays" ColumnName="Pays" />

            <ScalarProperty Name="Rue" ColumnName="Rue" />

            <ScalarProperty Name="CodePostal" ColumnName="CodePostal" />

            <ScalarProperty Name="Ville" ColumnName="Ville" />

          </ComplexProperty>

        </MappingFragment>

      </EntityTypeMapping>

    </EntitySetMapping>

  </EntityContainerMapping>

</Mapping>

On y remarque le mapping entre l'entité Client et la table Client, ainsi qu'entre le type complexe CustomModel.Adresse et la table Client.

Passons maintenant à la définition des classes et du contexte. 2 choix sont possibles, soit :

Utiliser le custom tool fourni par Visual Studio 2008 ou l'outil "edmgen.exe" pour générer les classes et le contexte à partir du fichier CSDL.

Définir/Modifier à la main vos propres classes d'entité. Cette méthode est utile lorsque vous possédez déjà vos classes métier. Cela consiste à implémenter pour chaque entité les interfaces IPOCO d'Entity Framework et d'ajouter quelques attributs.

Pour faire simple, voici la démarche pour utiliser le Custom Tool "EntityModelCodeGenerator" :

Sélectionnez le schéma conceptuel (fichier CSDL) dans Visual Studio.

Dans la fenêtre de propriétés, définissez la propriété Custom Tool à "EntityModelCodeGenerator".

A chaque sauvegarde du fichier CSDL, un fichier contenant les classes d'entité et le contexte est généré.

Et voila, si tout s'est bien passé, Client possède maintenant une variable de type Adresse, qui est notre type complexe.

Vous trouverez dans l'archive ci-dessous le code source de l'article et les scripts SQL Serveur 2005 de la base de données.

Différentes façons de créer dynamiquement une méthode (3/3)

2009-01-22T22:50:00.004+01:00

Ce billet es t le 3ème et dernier de la série. Tout comme les 2 précédents, il traite de la création dynamique d'une méthode et de son exécution.

Avec Mono.Cecil :

Tout d'abord, qu'est ce que Mono ? C'est un projet Open-Source supporté par Novell. Celui-ci a pour but de fournir une machine virtuelle, les compilateurs C# 3.0 et VB.Net (il doit y en avoir d'autres) et supporte notamment Silverlight (projet MoonLight). Mono.Cecil est un sous projet de Mono et propose à peu près les mêmes fonctionnalités que les classes des espaces de nom System.Reflection et System.Reflection.Emit.

D'une manière générale, Mono.Cecil est plus performant que son homologue et offre plus de possibilités. Patrick Smacchia a écrit un billet à ce sujet si cela vous intéresse.

Comparé au billet précédent, l'utilisation de Mono.Cecil, pour générer et exécuter dynamiquement une méthode, est sensiblement pareille. Il y a cependant quelques exceptions :

Je n'ai pas réussi à utiliser directement la méthode générée. J'ai du créer un assemblage à partir de la définition de l'assemblage modifié. Il doit être possible de faire autrement, mais je n'ai pas trouvé comment …

Mono.Cecil fait bien la distinction entre les TypeDef et le TypeRef (c'est un sujet un peu avancé j'avoue, même pour moi …). En gros, un TypeDef (définition de type) contient toutes les métadonnées pour un type donné, comme par exemple sa classe mère, les interfaces implémentées, les méthodes et les propriétés qui le composent, etc … Un typeRef (référence à un type) contient uniquement le nom du type et une variable faisant référence à l'assemblage/module auquel il appartient. Du coup, avec l'espace de nom System.Reflection, il se peut qu'on obtienne parfois des exceptions car on utilise sans le savoir un TypeRef alors qu'il faudrait un TypeDef …

Voici donc le code définissant et exécutant la méthode créée dynamiquement :

var defAssembly = AssemblyFactory.GetAssembly(Assembly.GetExecutingAssembly().Location);

addGeneratedMethod(defAssembly);

var modifiedAssembly = AssemblyFactory.CreateReflectionAssembly(defAssembly);

var modifiedType = modifiedAssembly.GetType("DynamicIL.Program");

modifiedType.GetMethod("helloCecil").Invoke(null, null);

Voilà l'explication de chaque instruction :

Premièrement, on récupère une définition de l'assemblage.

On fait appel à la méthode addGeneratedMethod qui créé et ajoute une méthode statique au type de la classe contenant la méthode Main. Son implémentation est expliquée juste après.

Un assemblage est créé à partir de la définition de l'assemblage modifié.

On récupère le type de la classe DynamicIL.Program?.

La méthode générée est appelée.

Voyons maintenant le corps de la méthode addGeneratedMethod :

private static void addGeneratedMethod(AssemblyDefinition pAssembly)

    var type = pAssembly.MainModule.Types.Cast<TypeDefinition>().Where(typeDef => typeDef.Name == "Program").First();

    var methodAttributes = Mono.Cecil.MethodAttributes.Public  Mono.Cecil.MethodAttributes.Static;

    TypeReference voidType = pAssembly.MainModule.Import(typeof(void));

    MethodDefinition methodDef = new MethodDefinition("helloCecil", methodAttributes, voidType);

    MethodInfo methodInfo = typeof(System.Console).GetMethod("WriteLine", new Type[] { typeof(string) });

    var methodRef = pAssembly.MainModule.Import(methodInfo);

    CilWorker cilWorker = methodDef.Body.CilWorker;

    cilWorker.Emit(Mono.Cecil.Cil.OpCodes.Ldstr, "Hello World avec Mono.Cecil !");

    cilWorker.Emit(Mono.Cecil.Cil.OpCodes.Call,methodRef);

    cilWorker.Emit(Mono.Cecil.Cil.OpCodes.Ret);

    type.Methods.Add(methodDef);

Voici le détail de l'implémentation de la méthode:

On récupère la définition du type Program.

Une énumératoin Mono.Cecil.MethodAttributes est assignée pour que la méthode générée soit publique et statique.

Une référence au type void est récupérée. Celle-ci sert aussi à la création de la méthode statique.

Via une instance de la classe MethodDefinition, on définie la signature de la méthode. Celle-ci s'appelle helloCecil, elle est publique ainsi que statique et renvoie un type void (c'est-à-dire rien).

Les 2 instructions suivantes servent à récupérer une référence à la méthode WriteLine de la classe Console prenant une chaine de caractère en paramètre.

Les 4 instructions d'après permettent de définir le corps de la méthode de la méthode avec des instructions MSIL. Celles-ci sont équivalentes à celles utilisées dans l'exemple précédent.

Finalement, la définition de la méthode est ajoutée à la définition du type "Program".

A l'exécution du programme, vous devriez voire apparaître à l'écran "Hello World avec Mono.Cecil !".

Pour plus d'informations, l'archive ci-dessous reprend le code des 3 méthodes de génération dynamique présentées.

Différentes façons de créer dynamiquement une méthode (2/3)

2009-01-22T15:59:00.004+01:00

Ce billet est le 2ème de la série. Il traite de la création dynamique d'une méthode.

Avec l'espace de nom System.Reflection.Emit :

Alors que l'espace de nom System.Reflection contient les classes nécessaires pour interroger la structure du code en .Net, l'espace de nom System.Reflection.Emit permet de modifier dynamiquement les différents éléments (classes, structures, énumérations, etc …) du langage.

Pour ce qui concerne la génération d'une méthode à l'exécution, cela se fait simplement avec la classe System.Reflection.Emit.DynamicMethod ,tout du moins pour la déclaration de la méthode. Ensuite, et c'est là où ça devient un peu plus compliqué, il faut rajouter les instructions composant le corps de la méthode en injectant des instructions MSIL.

MSIL pour MicroSoft Intermediate Language ou CIL (Common Intermediate Language) est le langage intermédiaire utilisé par la machine virtuelle du Framework .Net. Celui-ci est ensuite compilé pour pouvoir être exécuté sur la machine hôte. En fait, les compilateurs de la plateforme .Net, comme celui du C# ou de VB .Net transforment le code produit par le développeur en langage MSIL.

Vous trouverez un tutorial en anglais sur le MSIL à l'adresse suivante : http://weblogs.asp.net/kennykerr/archive/2004/09/07/introduction-to-msil-part-1-hello-world.aspx. Comparé à un langage comme l'assembleur, le MSIL est orienté objet et adopte la notion de piles.

Je vous rassure, je ne suis pas du tout un expert en MSIL, enfin pas encore ! Pour m'y retrouver, j'utilise Reflector qui permet de décompiler un assemblage .Net et de voir le code MSIL produit. En comparant avec le code C# ou VB.Net, il est possible de s'y retrouver.

Passons maintenant au code, voici les instructions définissant notre méthode, faisant appel à une procédure définissant le corps de la méthode, un délégué est ensuite créé et assigné, et finalement celui-ci est appelé.

DynamicMethod dynMeth = new DynamicMethod("foo", typeof(void), null, typeof(Program));

WriteHello(dynMeth.GetILGenerator());

Method meth1 = (Method)dynMeth.CreateDelegate(typeof(Method));

meth1();

Le constructeur de DynamicMethod utilisé prend en paramètre:

Le nom de la méthode : "foo"

Le type renvoyé : typeof(void)

Un tableau de Type définissant les types des arguments de la méthode : null (notre méthode ne prend aucun argument)

Le type qui reçoit cette nouvelle méthode : typeof(Program). Pour l'exemple, c'est le nom de la classe contenant la méthode statique main.

Voici maintenant le corps de la procédure WriteHello(ILGenerator) qui définit le corps de la méthode générée :

static void WriteHello(ILGenerator cg)

    cg.Emit(System.Reflection.Emit.OpCodes.Ldstr, "Hello World avec System.Reflection.Emit !");

    cg.Emit(System.Reflection.Emit.OpCodes.Call,

    typeof(System.Console).GetMethod("WriteLine",

    new Type[] { typeof(string) }));

    cg.Emit(System.Reflection.Emit.OpCodes.Ret);

Premièrement, on ajoute sur la pile la chaine de caractères "Hello World avec System.Reflection.Emit !". En MSIL, il est obligatoire de faire cela pour utiliser une constante. La 2ème instruction fait un appel à la méthode statique Console.WriteLine prenant en argument une chaine de caractère. La chaine de caractère utilisée est celle qui est en haut de la pile, c'est dire "Hello World avec System.Reflection.Emit !". La dernière instruction signifie la fin du corps de la méthode (ceci correspond à return;).

Après compilation, vous devriez voir apparaître dans la console "Hello World avec System.Reflection.Emit !". C'est magique non ?!

Pour plus d'informations, l'archive ci-dessous reprend le code des 3 méthodes de génération dynamique présentées.

Différentes façons de créer dynamiquement une méthode (1/3)

2009-01-22T13:26:00.017+01:00

Dernièrement, j'avais cherché à créer une méthode grâce à l'API CodeDom, de générer/compiler un assemblage, de le charger en mémoire et enfin d'exécuter la méthode générée.

Cette méthode fonctionne, cependant elle a l'inconvénient de passer par une compilation du C# en MSIL avant de pouvoir enfin exécuter la méthode générée.
Je me suis demandé alors si c'était possible de générer et d'injecter dynamiquement une méthode dans l'assemblage utilisé ou ailleurs et de l'exécuter par la suite. En cherchant sur la toile, je suis tombé sur 4 solutions abordables :

Utiliser les classes de l'espace de nom System.Reflection.Emit

Utiliser les arbres d'expressions de LinQ

Utiliser Mono.Cecil qui est un projet open source.

Utiliser l'API bas niveau de PostSharp. C'est un framework de programmation orientée aspect.

J'ai donc mis en œuvre les 3 premières solutions, c'est-à-dire une implémentation avec System.Reflection.Emit, les arbres d'expressions et Mono.Cecil. Concernant PostSharp, je pense que je m'y pencherai un autre jour.

Pour information, chaque méthode générée est un simple Hello World affichée dans la console.

Avec les arbres d'expressions

Commençons par l'implémentation la plus facile, celle utilisant les arbres d'expressions. Succinctement, un arbre d'expressions est une structure de données représentant du code. Il est ensuite possible de générer une méthode dynamiquement. Dans LinQ , les arbres d'expressions sont utilisés avec l'interface IQueryable et le type générique Expression. Ce dernier est toujours associé à des expressions lambdas, qui ne sont rien d'autres que des méthodes anonymes composée d'une seule instruction (comprenez un seul point-virgule ;). Ensuite le compilateur C# ou VB.Net transforme l'expression lambda en un arbre d'expression.

Pour information, LinQ to SQL et LinQ to Entities utilisent les arbres d'expressions pour transformer une expression lambda (condition dans un méthode Where par exemple) en SQL.

L'instruction suivante :

Expression<Action> expr = () => Console.WriteLine("Hello World avec les arbres d'expression !");

Donne après décompilation avec Reflector :

Expression<Action> expr = Expression.Lambda<Action>(

                                    Expression.Call(null,

                                                    typeof(System.Console).GetMethod("WriteLine", new Type[] { typeof(string) }),

                                                    new Expression[] { Expression.Constant("Hello World avec les arbres d'expression !", typeof(string)) }),

                                    new ParameterExpression[0]);

On s'aperçoit que le compilateur C# a transformé notre expression lambda en un arbre d'expressions.
Pour plus de détails sur les arbres d'expressions, voici le lien MSDN.

Voici donc le code pour générer notre HelloWorld de façon dynamique et avec les arbres d'expression :

Expression<Action> expr = Expression.Lambda<Action>(

                                    Expression.Call(null,

                                                    typeof(System.Console).GetMethod("WriteLine", new Type[] { typeof(string) }),

                                                    new Expression[] { Expression.Constant("Hello World avec les arbres d'expression !", typeof(string)) }),

                                    new ParameterExpression[0]);

var meth2 = expr.Compile();

meth2();

A la 1ère ligne, l'expression lambda est définie et assignée au type Expression. Ce code une fois compilé résulte donc en un arbre d'expressions. En d'autres termes, Le compilateur C# a transformé la logique de l'expression lambda en données. Pour transformer ensuite l'arbre d'expressions en logique, il suffit simplement d'appeler la méthode Compile de la classe Expression . Cette méthode retourne un délégué qui représente la méthode générée.

Petite remarque, il est très facile de générer du code via les arbres d'expressions. Cependant, un arbre ne peut contenir que l'équivalent d'une instruction, tout comme les expressions lambdas. Du coup, pas besoin de connaitre le MSIL.

Nous verrons dans le prochain billet comment générer une méthode avec les classes de l'espace de nom System.Reflection.Emit.

Pour plus d'informations, l'archive ci-dessous reprend le code des 3 méthodes de génération dynamique présentées.

Générer un flux RSS avec LinQ To XML

2009-01-19T18:16:00.008+01:00

LinQ To XML permet de manipuler les fichiers et les flux XML. C'est la dernière API XML de Microsoft et celle-ci offre l'avantage d'être beaucoup plus facile à utiliser que XmlTextReader/XmlTextWriter, grâce à son style fonctionnel.

Dernièrement, j'ai du générer quelques flux RSS pour un projet Sharepoint. Je me suis donc servi de LinQ To XML pour créer les flux en question.

Voici donc le code nécessaire pour générer un flux RSS avec LinQ To XML :

public class ItemRSS

    public string Titre { get; set; }

    public string Lien { get; set; }

    public string Description { get; set; }

    public string Auteur { get; set; }

    public string Date { get; set; }

    public string Source { get; set; }

    public string Catégorie { get; set; }

    public string Guid { get; set; }

public static string BuildRSS(string pTitreRSS,

                              string pLienRSS,

                              string pDescription,

                              string pLanguage,

                              string pPubDate,

                              string pDerniereDate,

                              string pNomGenerateur,

                              string pMailResponsable,

                              IEnumerable<ItemRSS> pListeItems)

    XDocument xdoc = new XDocument(

                        new XDeclaration("1.0", "UTF-8", "yes"),

                        new XElement("rss",

                            new XElement("channel",

                                new XElement("title", pTitreRSS),

                                new XElement("link", pLienRSS),

                                new XElement("description", pDescription),

                                new XElement("language", pLanguage),

                                new XElement("pubDate",pPubDate),

                                new XElement("lastBuildDate",pDerniereDate),

                                new XElement("generator", pNomGenerateur),

                                new XElement("webMaster",pMailResponsable),

                                from item in pListeItems

                                select new XElement("item",

                                    new XElement("title", item.Titre),

                                    new XElement("link", item.Lien),

                                    new XElement("description", new XCData(item.Description)),

                                    new XElement("author", item.Auteur),

                                    new XElement("pubDate", item.Date),

                                    new XElement("guid", item.Lien),

                                    new XElement("source",item.Source),

                                    new XElement("category",item.Catégorie))),

                            new XAttribute("version", "2.0")));

    return xdoc.ToString();

La classe ItemRSS représente un item du flux RSS et chaque propriété publique représente un élément de l'item.

La méthode statique BuildRSS prend en paramètre quelques valeurs définissant les éléments enfants de l'élément channel d'un flux RSS et prend aussi en paramètre la liste des items contenus dans le flux RSS.

En une seule instruction, celle du constructeur de la classe XDocument, la méthode BuildRSS construit l'intégralité du flux RSS. Un élément XML du style <title>titre</title> est représenté par l'instruction suivante : new XElement("title","titre"). Une déclaration XML est représentée par la classe Xdeclaration et un attribut par XAttribute.

Les classes XDocument et XElement peuvent aussi prendre en paramètre dans leur constructeur un tableau d'objets (params object[]), ce qui permet facilement de définir les enfants d'un élément XML.

Vous trouverez ci-dessous un exemple d'application Console utilisant ce code pour générer un flux RSS (nécessite Visual Studio 2008).

Récupérer la valeur d'une propriété d'un objet à partir de son nom

2009-01-19T12:51:00.006+01:00

Si vous souhaitez récupérer la valeur d'une propriété ou d'une variable membre publique à partir de son nom, voici 2 méthodes utilitaires permettant de faire cela grâce à la réflexion :

class Objet

    public string Nom { get; set; }

    public string Variable;

public static class Util

    public static T GetValeurProp<T>(this object pObjet, string pNom)

        return (T)pObjet.GetType().GetProperty(pNom).GetValue(pObjet, null);

    public static T GetValeurField<T>(this object pObjet, string pNom)

        return (T)pObjet.GetType().GetField(pNom).GetValue(pObjet);

class Program

    static void Main(string[] args)

        var obj = new Objet() { Nom = "Propriété", Variable = "variable membre publique" };

        Console.WriteLine(obj.GetValeurProp<string>("Nom"));

        Console.WriteLine(obj.GetValeurField<string>("Variable"));

        Console.ReadKey();

Grâce aux méthodes GetField(string) et GetProperty(string) de la classe Type, il est possible de récupérer respectivement une variable membre publique et une propriété publique d'une classe à partir d'une chaine de caractères. Après il suffit simplement d'appeler la méthode GetValue des objets FieldInfo et PropertyInfo pour récupérer la valeur de la propriété ou de la variable membre.

Redirection dans un bloc Try Catch

2008-12-30T15:37:00.003+01:00

En voulant faire une simple redirection avec Response.Redirect("url") dans une page ASP.Net, je me suis heurté à un problème. Cette fonction appelle en interne la méthode Response.End() qui a pour rôle de terminer le thread en cours. Le problème c'est que cette méthode génère une exception de type System.Threading.ThreadAbortException.

Pas forcément de problème si je n'avais pas mis un block try {} catch(Exception exp) {} autour de la redirection … Du coup, une fois l'instruction de la redirection passée, je tombais à chaque fois dans le block catch {}. Il est à noter que le comportement est le même avec la méthode Microsoft.SharePoint.Utilities.SPUtility.Redirect("url",flags,Context) effectuant une redirection dans Sharepoint.

Une bonne solution est d'utiliser une surcharge de la méthode Response.Redirect prenant en plus un booléen à mettre à false. Ce dernier évitera l'appel à la méthode Response.End(). Vous pouvez aussi enlever le bloc try {} catch{} mais cela n'est pas très propre.

Charger une dll dynamiquement

2008-12-30T11:14:00.002+01:00

Grâce à la réflexion, il est tout à fait possible de charger une dll dynamiquement. La classe System.Reflection.Assembly contient une méthode statique LoadFrom prenant comme argument dans une méthode surchargée, une chaine de caractère. En passant à la fonction le nom de la dll, on récupère une référence de l'assembly contenu dans la dll.


string dllName = ConfigurationSettings.AppSettings["dll"];
Assembly assembly = Assembly.LoadFrom(dllName);

A partir de cette référence, il est possible d'instancier un type contenu dans l'assembly. Seulement pour manipuler facilement ce type (sans réflexion), il faut connaitre sa classe, ou du moins une interface ou une classe abstraite dont il hérite. Imaginons que ce type hérite d'une interface appelée IInterface contenant une méthode executer() qu'il implémente, voici un bout de code permettant d'invoquer cette fonction :


string typeName = ConfigurationSettings.AppSettings["type"];
Type dllType = assembly.GetType(typeName);
IInterface obj = Activator.CreateInstance(dllType) as IInterface;
obj.executer();

Dans les 2 exemples ci-dessus, je récupère le nom de la dll et du type dans le fichier de configuration de l'application (de type Console pour l'exemple). Ceci est une bonne façon de faire, si vous souhaitez spécifier une autre dll et un autre type sans recompilation. Voici le fichier de configuration de l'exemple :


<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="dll" value="library.dll"/>
    <add key="type" value="library.Class1"/>
  </appSettings>
</configuration>

Pour plus d'infos, veuillez vous référer à l'archive ci-présente :

Sharepoint : Provisioning de pages dans un site de publication

2008-12-29T15:53:00.005+01:00

Dernièrement, j'ai du créer une mise en page (page layout) pour un site de publication. Toutes les pages utilisant cette mise en page contiennent les 2 mêmes webparts ainsi qu'un champ de type HTML remplie toujours de la même manière.

J'ai donc cherché à provisionner la mise en page, pour qu'à la création d'une page, les 2 webparts et le contenu HTML soient ajoutés automatiquement. Sharepoint propose une solution simple de fichier XML et de CAML, dont voici un exemple :

   1:  <Elements xmlns="http://schemas.microsoft.com/sharepoint/">

   2:      <File Url="PressWIBLayout.aspx" Type="GhostableInLibrary" IgnoreIfAlreadyExists="TRUE">

   3:        <Property Name="Title" Value="Press WIB Layout" />

   4:        <Property Name="MasterPageDescription" Value="PressWIBLayout" />

   5:        <Property Name="ContentType" Value="$Resources:cmscore,contenttype_pagelayout_name;" />

   6:        <Property Name="PublishingPreviewImage" Value="~SiteCollection/_catalogs/masterpage/Preview Images/SAMPLELayout.png, ~SiteCollection/_catalogs/masterpage/Preview Images/SAMPLELayout.png" />

   7:        <Property Name="PublishingAssociatedContentType" Value=";#$Resources:xxx,ContentType_Page_Title;;#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF390064DEA0F50FC8C147B0B6EA0636C4A7D400ABEA1C761C4D4268997A1EBE2A5C8EA6;#" />

   8:        <Property Name="Footer" Value="&lt;div class=&quot;pageFooter topic&quot;&gt;&lt;p&gt;$Resources:xxx,SiteTemplate_SPS_FooterTopic;&lt;/p&gt;&lt;/div&gt;" />

   9:        <AllUsersWebPart WebPartZoneID="ZoneMainRightCol" WebPartOrder="1">

  10:          <![CDATA[

  11:  <webParts>

  12:    <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">

  13:      <metaData>

  14:        <type name="XX.XXX.Runtime.Webparts.FeedBack, XX.XXX.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=xxxxxxxxxx" />

  15:        <importErrorMessage>Impossible d'importer ce WebPart.</importErrorMessage>

  16:      </metaData>

  17:      <data>

  18:        <properties>

  19:          <property name="AllowClose" type="bool">True</property>

  20:          <property name="Width" type="string" />

  21:          <property name="AllowMinimize" type="bool">True</property>

  22:          <property name="AllowConnect" type="bool">True</property>

  23:          <property name="ChromeType" type="chrometype">Default</property>

  24:          <property name="TitleIconImageUrl" type="string" />

  25:          <property name="Description" type="string" />

  26:          <property name="Hidden" type="bool">False</property>

  27:          <property name="TitleUrl" type="string" />

  28:          <property name="AllowEdit" type="bool">True</property>

  29:          <property name="Height" type="string" />

  30:          <property name="MissingAssembly" type="string">Impossible d'importer ce composant WebPart.</property>

  31:          <property name="HelpUrl" type="string" />

  32:          <property name="Title" type="string">XXX:: Feed Back</property>

  33:          <property name="CatalogIconImageUrl" type="string" />

  34:          <property name="Direction" type="direction">NotSet</property>

  35:          <property name="ChromeState" type="chromestate">Normal</property>

  36:          <property name="AllowZoneChange" type="bool">True</property>

  37:          <property name="AllowHide" type="bool">True</property>

  38:          <property name="HelpMode" type="helpmode">Modeless</property>

  39:          <property name="ExportMode" type="exportmode">All</property>

  40:        </properties>

  41:      </data>

  42:    </webPart>

  43:  </webParts>

  44:            ]]>

  45:        </AllUsersWebPart>

  46:        <AllUsersWebPart WebPartZoneID="ZoneRightTopCol" WebPartOrder="1">

  47:          <![CDATA[

  48:  <webParts>

  49:    <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">

  50:      <metaData>

  51:        <type name="XX.XXX.Runtime.Webparts.LatestWIBs, XX.XXX.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=xxxxxxxxxxx" />

  52:        <importErrorMessage>Cannot import this Web Part.</importErrorMessage>

  53:      </metaData>

  54:      <data>

  55:        <properties>

  56:          <property name="Title" type="string">XXX:: latest weeks in brief</property>

  57:          <property name="WIBTitle" type="bool">False</property>

  58:          <property name="NumberOfElements" type="int">1</property>

  59:        </properties>

  60:      </data>

  61:    </webPart>

  62:  </webParts>

  63:            ]]>

  64:        </AllUsersWebPart>

  65:      </File>

  66:    </Module>

  67:  </Elements>

L'attribut Url de l'élément File spécifie la mise en page concernée et l'attribut IgnoreIfAlreadyExists=TRUE dit à Sharepoint que si la mise en page existe déjà, ce n'est pas la peine de la rajouter.

Après compilation, déploiement et activation, le résultat est impeccable : une page créée avec la mise en page ci-dessus contient bien mes 2 webparts. Cependant, je souhaitais modifier quelques propriétés dans une des 2 webparts. Je recompile, redéploie et réactive ma feature. Lorsque je recréée une page, je m'aperçois que ma page contient, non pas 2 webparts, mais 4, 2 de chaque en fait.

En faisant quelques tests, je me rends compte qu'a chaque fois que je désactive/réactive la feature, une instance pour chaque webpart spécifiée dans le module XML est ajoutée à chaque page créée avec cette mise en page. Pourtant, j'ai bien spécifié d'ignorer la mise en page si elle existe déjà dans le catalogue de la collection de site, via l'attribut IgnoreIfAlreadyExists défini à true.

En fait, la mise est bien ignorée si elle existe déjà. Malheureusement, ce n'est pas le cas des webparts spécifiées à l'intérieur. Pour moi, ceci est un bug de Sharepoint, peut-être est-il déjà référencé par Microsoft … Une autre solution de provisioning serait d'utiliser un EventReceiver ajoutant les webparts voulues à la création d'une page.

Article sur Entity Framework

2008-12-18T16:31:00.000+01:00

Developpez.com vient de publier un article que j'ai écrit sur Entity Framework, la solution mapping objet-relationnel de Microsoft : http://pmusso.developpez.com/tutoriels/dotnet/entity-framework/introduction/.

Dans l'article, vous trouverez une partie théorique sur le framework expliquant entre autre le concept d'entités, ce qu'est le modèle conceptuel et ses 3 schémas XML.

Dans une 2ème partie, vous apprendrez à vous servir de l'assistant de Visual Studio pour générer vos objets métiers à partir d'une base de données déjà établie.

En dernier lieu, l'utilisation des entités et du contexte sont expliqués en détail. Vous trouverez aussi quelques informations sur l'accès concurrentiel et les transactions.

Bonne lecture ! :)

POCO avec Entity Framework (1/2)

2008-12-10T21:39:00.004+01:00

Qu'est-ce que POCO déjà ?

Cela signifie Plain Old Code Object. Le "C" peut vouloir dire aussi CSharp ou CLR Object. Dans le monde Java on retrouve ainsi l'acronyme POJO qui veut dire Plain Old Java Object, mais le sens est le même.

POCO signifie de laisser tel quel ses classes métiers lorsqu'on souhaite les rendre persistantes avec un outil de mapping objet-relationnel. C'est à dire que les classes métiers ne sont pas modifiées pour les faire fonctionner avec l'outil.

Entity Framework fonctionne avec des entités. Ce sont des classes dérivant de la classe System.Data.Objects.DataClasses.EntityObject. Une autre solution est d'implémenter 3 interfaces fournies par le framework .Le problème avec ce design, c'est que les classes métiers doivent être modifiées pour fonctionner avec Entity Framework. Du coup, on en déduie qu'Entity Framework ne supporte pas le concept POCO, en tout cas pas dans sa version 1.

L'équipe d'Entity Framework travaille sur une solution afin d'annuler la dépendance qu'il existe entre les classes métiers et le framework. Vous trouverez une partie de leur reflexion sur un de leur blog.

Une autre solution appellée PostSharp4EF a été proposée par Ruurd Boeke. Celle-ci est plutôt élégante car elle utilise la programmation orientée aspect (avec Postsharp) pour implémenter lors d'une 2ème compilation les interfaces requises pour rendre persistentes nos classes POCO.

PostSharp4EF exécute entre autres les tâches suivantes :

implémente les interfaces IPOCO : IEntityWithChangeTracker, IEntityWithKey et IEntityWithRelaships
Ajoute l'attribut EdmEntityType sur la classe, l'attribut EdmScallarProperty sur chaque propriété, l'attribut EdmRelashionShip et EdmSchema sur l'assembly

Toutes ces tâches sont exécutées grâce à PostSharp et à l'attribut [assembly: Poco("InheritanceTypeConnection")], celui-ci étant implémenté par PostSharp4EF.

Nous verrons dans un prochain billet un petit exemple d'implémentation.

Exécuter une chaine de caractère avec CodeDom et la réflexion

2008-12-03T13:59:00.007+01:00

Grâce à l'API CodeDom, il est assez facile de générer des assemblies dynamiquement. Le framework .Net permet d'exécuter un assembly grâce à la réflexion. A partir de ces 2 constats, il devient possible d'exécuter une chaine de caractère contenant du code, un peu comme on le ferait dans un langage de script.

Dans un langage statique comme le C#, le code doit d'abord être compilé, ce que CodeDom fait très bien. Il ne reste plus qu'à utiliser la réflexion pour exécuter le code compilé. Voici l'exemple d'une fonction montrant cela :

   1:  using System;

   2:  using System.CodeDom;

   3:  using System.CodeDom.Compiler;

   4:  using System.Reflection;

5:

   6:  namespace GenererMethode

   7:  {

   8:      public class Generateur

   9:      {

  10:          public static void Executer(string[] references, string[] usings, string strCode)

  11:          {

  12:              CompilerParameters compilerParameters = new CompilerParameters();

  13:              compilerParameters.GenerateExecutable = false;

  14:              compilerParameters.GenerateInMemory = true;

  15:              compilerParameters.IncludeDebugInformation = true;

16:

  17:              foreach (string reference in references)

  18:              {

  19:                  compilerParameters.ReferencedAssemblies.Add(reference);

  20:              }

21:

  22:              CodeCompileUnit code = new CodeCompileUnit();

  23:              code.UserData.Add("AllowLateBound", false);

  24:              code.UserData.Add("RequireVariableDeclaration", true);

25:

  26:              CodeNamespace nameSpace = new CodeNamespace("GenererMethode");

  27:              foreach (string _using in usings)

  28:              {

  29:                  nameSpace.Imports.Add(new CodeNamespaceImport(_using));

  30:              }

  31:              code.Namespaces.Add(nameSpace);

32:

  33:              CodeTypeDeclaration classObject = new CodeTypeDeclaration("Test");

  34:              nameSpace.Types.Add(classObject);

  35:              classObject.TypeAttributes = TypeAttributes.Public;

36:

  37:              CodeMemberMethod method = new CodeMemberMethod();

  38:              method.Attributes = MemberAttributes.Public  MemberAttributes.Static;

  39:              method.Name = "HelloWorld";

  40:              CodeSnippetExpression csu = new CodeSnippetExpression(strCode);

  41:              method.Statements.Add(csu);

  42:              classObject.Members.Add(method);

43:

  44:              CodeGenerator.ValidateIdentifiers(code);

45:

  46:              CodeDomProvider codeProvider = CodeDomProvider.CreateProvider("C#");

47:

  48:              var result = codeProvider.CompileAssemblyFromDom(compilerParameters, code);

49:

  50:              Assembly assembly = result.CompiledAssembly;

  51:              Type type = assembly.GetType("GenererMethode.Test");

  52:              type.InvokeMember("HelloWorld", BindingFlags.InvokeMethod, null, null, null);

  53:          }

  54:      }

  55:  }

La méthode "Executer" crée une classe quelconque et créé aussi une méthode statique contenant la chaine de caractère passée en paramètre. Pour que le code de la chaine de caractères puisse s'exécuter, la méthode prend en paramètre les dll contenant les assemblies et les usings nécessaires. Finalement, la méthode générée est exécutée via la réflexion.

   1:  Generateur.Executer(new string[] { "System.dll" },

   2:                                  new string[] { "System" },

   3:                                  "Console.WriteLine(\"Hello World\")");

Peut-on utiliser des classes métiers n'héritant pas de "EntityObject" ?

2008-11-27T14:50:00.000+01:00

La réponse est oui ! Au minimum, il est nécessaire que vos classes héritent des interfaces suivantes :

IEntityWithChangeTracker : Active le suivi des modifications.

IEntityWithKey. Facultatif : Expose une clé d'entité.

IEntityWithRelationships : Obligatoire pour les entités présentant des associations.

Pour plus d'informations, voici la documentation officielle.

Implémenter ces 3 interfaces sous entend que vos classes métiers doivent être modifiées pour utiliser la persistance avec Entity Framework. En d'autres termes, le principe de faible couplage / forte cohérence n'est pas respecté puisque les classes métiers contiennent à la fois de la logique métier et de la logique de persistance. De plus, dans certains scénarios, il n'est pas possible de modifier ses classes métiers.

On peut en tirer la conclusion suivante : Entity Framework ne permet pas d'utiliser des classes POCO (pour Plain Old Code Object). D'autres outils le permettent comme NHibernate avec l'utilisation d'objets proxy. Danny Simmons, développeur de l'équipe d'Entity Framework s'explique à ce sujet. Souhaitons que ce manque soit comblé dans les prochaines versions de l'outil.

Cependant, sachez qu'il est possible de contourner ce manque avec l'utilisation de la programmation orientée aspect. Sans rentrer dans les détails, PostSharp permet d'injecter du code lors d'une 2ème phase de compilation et donc d'implémenter les 3 interfaces nécessaires sur les classes POCO. Un projet a d'ailleurs été réalisé à ce sujet. Vous trouverez plus d'information sur son blog.

Lecture des données

2008-11-25T13:44:00.001+01:00

Entity Framework offre 3 types de possibilité pour requêter la source de données :

LinQ To Entities

Entity SQL

Les méthodes génératrices de requête de "ObjectQuery<T>"

LinQ To Entities permet d'écrire des requêtes syntaxiquement proche du SQL, et cela directement en C# ou VB.Net. L'avantage majeur vient du fait que les requêtes produites sont vérifiées à la compilation et non plus à l'exécution. Comme pour chaque implémentation de LinQ, chaque requête est transformée en un arbre d'expression (créé par l'objet ObjectContext) qui est traduit en SQL par le fournisseur de données final. Le résultat d'une requête LinQ to Entities est de type "IQueryable<T>" où T est le type spécifié dans la clause SELECT de la requête.
Voici donc un exemple de requête LinQ to Entities :


var requete = from publication in bdd.Publication
                         select publication;

Le résultat est de type "IQueryable<Publication>". Il est possible d'itérer sur les résultats avec une simple boucle "foreach". Vu que "IQueryable<T>" implémente un énumérateur, sachez que la requête vers la source de données est uniquement exécutée lors du parcours des résultats. Pour plus d'information, veuillez vous référencer à la documentation officielle de l'objet "IQueryable<Publication>".
Linq to Entities supporte un ensemble de méthodes pour requêter la source de données dont voici une liste non exhaustive (url de la liste complète) :

Select, SelectMany

Where

GroupJoin, Join

All, Any

Distinct

Except

Intersect

Union

OrderBy, OrderByDescending, ThenBy, ThenByDescending

GroupBy

Average

Count, LongCount

Max, Min, Sum

OfType, Cast

First, FirstOrDefault

Skip, Take

Voici l'exemple d'une requête sélectionnant seulement les publications qui contiennent le mot "C#" dans leur titre :


var requete = from publication in bdd.Publication
                         where publication.Titre.Contains("C#")
                         select publication;

Pour plus d'informations sur les requêtes LinQ, je vous invite à lire l'article de Thomas Lebrun.
Il est aussi possible de requêter la source de données grâce à Entity SQL. C'est un langage héritant du vocabulaire et de la grammaire de type SQL. Ce langage permet de récupérer des produits scalaires, des ensembles de résultat et des graphes d'objet. Pour une description du langage, veuillez vous référer à la documentation officielle.
Voici l'exemple d'une requête récupérant toutes les publications stockées en base :


string chaineRequete = "SELECT VALUE p FROM Publication AS p";

// Définition de la requête de type ObjectQuery<Publication>
ObjectQuery<Publication> requete = new ObjectQuery<Publication>(chaineRequete, bdd, MergeOption.NoTracking);

En dernier choix, vous pouvez utiliser les méthodes du générateur de requêtes de la classe "ObjectQuery<T>". En voici un exemple :


// Définition de la requête de type ObjectQuery<Publication>
var requete = bdd.Publication.SelectValue<Publication>("it");

La suite de l'article fera uniquement référence à LinQ to Entities, mais toutes les requêtes faites sur le modèle peuvent être réalisées avec Entity SQL ou grâce aux méthodes du générateur de requêtes de la classe "ObjectQuery<T>".
Chaque entité en relation avec une autre possède une collection d'entités connexes. Cependant, celle-ci n'est pas initialisée par défaut. Pour naviguer vers ces entités, il est nécessaire de les charger explicitement :

soit en utilisant la méthode "Include" de "ObjectQuery<T>",

soit en utilisant la méthode "Load" appartenant à la classe "EntityReference<T>" ou à "EntityCollection<T>".

L'exemple suivant utilise la méthode "Include" pour récupérer explicitement, lors de la requête, l'éditeur et les auteurs associés aux publications :


using (Modele bdd = new Modele())
{
    var requete = from publication in bdd.Publication.Include("Auteur").Include("Editeur") select publication;
       
    requete.ToList().ForEach((Publication p) =>
    {
        Console.WriteLine("Publication : ID = {0}  Titre = {1}", p.Id, p.Titre);
       
        Console.WriteLine("     Editeur : ID = {0}  Nom = {1}", p.Editeur.Id, p.Editeur.Nom);
           
        p.Auteur.ToList().ForEach(a => Console.WriteLine("     Auteur : ID = {0}  Nom = {1} {2}",a.Id,a.Prenom,a.Nom));
    });
}

Voici un autre exemple avec l'utilisation de la méthode "Load". Remarquez que chaque collection ou chaque référence liée à une entité possède une propriété "IsLoaded" permettant de savoir si la ou les entités connexes sont chargées.


using (Modele bdd = new Modele())
{
    var requete = from publication in bdd.Publication select publication;

    requete.ToList().ForEach((Publication p) =>
    {
        if (!p.EditeurReference.IsLoaded)
            p.EditeurReference.Load();

        Console.WriteLine("     Editeur : ID = {0}  Nom = {1}", p.Editeur.Id, p.Editeur.Nom);

        if (!p.Auteur.IsLoaded)
            p.Auteur.Load();

        p.Auteur.ToList().ForEach(a => Console.WriteLine("     Auteur : ID = {0}  Nom = {1} {2}", a.Id,      a.Prenom, a.Nom));
    });
}

Quels sont les SGBDR supportés ?

2008-11-23T13:06:00.000+01:00

La couche "Object Services" d'Entity Framework s'appuie sur le fournisseur de données "EntityClient" pour qu'il exécute les requêtes LinQ transformées au préalable en arbres d'expression. "EntityClient" a pour but d'accéder aux données définies dans le modèle EDM décrits par les 3 fichiers CSDL, MSL et SSDL. Il génère ensuite un arbre d'expressions relatif aux données du schéma logique et l'envoie à un fournisseur de données spécialisées, afin que celui-ci transforme l'arbre en requêtes SQL.

Ce dernier fournisseur de données est spécifique à la base de données utilisée. Le fournisseur utilisé est défini par la chaine de connexion utilisée par l'objet "EntityConnection", qui a la responsable d'ouvrir la connexion de la source de données.

Voici un exemple de chaine de connexion, définit par l'assistant de Visual Studio 2008 :

metadata=res://*/modele.csdlres://*/modele.ssdlres://*/modele.msl;provider=System.Data.SqlClient;provider
connection string="Data Source=TLS-LOG-PO-PMO\SQLEXPRESS;Initial Catalog=helloentityfx;Integrated Security=True;MultipleActiveResultSets=True"

La 1ère partie concerne les métadonnées de la connexion. On y voit la référence aux 3 schémas du modèle EDM, et du fournisseur de données utilisé pour la base de données. Ici, c'est la classe "System.Data.SqlClient" qui permet de communiquer avec une base de type SQL Serveur 2005.

Il est donc possible de spécifier un autre fournisseur de données pour utiliser, par exemple, une base Oracle, MySQL ou PostgreSQL. Voici une liste non exhaustive des fournisseurs de données compatibles avec Entity Framework :

Oracle : http://devart.com/dotconnect/oracle/ (payant)

MySQL : http://devart.com/dotconnect/mysql/ (payant)

PostgreSQL : http://pgfoundry.org/frs/shownotes.php?release_id=1230 (gratuit)

SQLite : http://sqlite.phxsoftware.com/, http://devart.com/dotconnect/sqlite/ (gratuit)

Il est aussi possible de créer son propre fournisseur de données. Un projet sur Codeplex fournit le code nécessaire.

Concept d'Entity Framework

2008-11-20T14:58:00.004+01:00

Entity Framework est la solution de mapping objet relationnel proposée par Microsoft. Son but est de fournir la couche d'abstraction nécessaire aux développeurs pour qu'ils n'accèdent plus directement à la base de données, mais par l'intermédiaire d'entités définies par un modèle appelé EDM (Entity Data Model).

Ce modèle est divisé en 3 parties :

Le schéma conceptuel : Il regroupe la définition des entités, des ensembles d'entités et des fonctions utilisées. Ces éléments sont définis dans un fichier XML appelé CSDL (Conceptual Schema Definition Language).

Le schéma logique : Celui-ci correspond à la définition des tables, vues et procédures stockées déclarées dans la base de données. Toutes ces informations sont regroupées dans un fichier XML appelé SSDL (Store Schema Definition Language).

Schéma de liaison : Il définit les liaisons entre le schéma conceptuel et le schéma logique. Il associe entre autre les entités déclarées dans le fichier CSDL aux tables définies dans le fichier SSDL. Ce mapping est inscrit dans le fichier XML MSL (Mapping Specification Language).

Visual Studio 2008 SP1 intègre aussi un assistant permettant de générer un modèle EDM, et ce de manière graphique. Il ressemble assez à l'assistant LinQ to SQL pour les connaisseurs et il offre un confort d'utilisation bien meilleur que l'outil en ligne de commande, au détriment d'un certain manque de fonctionnalités.

Par exemple, il n'est pas possible de définir de type complexe avec l'assistant, alors que "EdmGen.exe" le permet. Rassurez-vous, vous pouvez commencer à utiliser l'assistant (gain de temps évident) et utiliser par la suite l'outil en ligne de commande. Néanmoins, il s'avère regrettable d'avoir recours à ce genre de manipulation. La prochaine version de l'assistant devrait corriger cela; et bien d'autres points.

Afficher correctement du code dans vos blogs

2008-11-10T13:36:00.012+01:00

Dernièrement, j'ai cherché une manière d'afficher correctement du code sur mon blog. En cherchant un petit peu, j'ai trouvé la balise HTML <pre> qui garde l'indentation des lignes. Rien qu'avec cela, le code publié est déjà beaucoup plus lisible. En voici un exemple :


using System.Collections.Generic;

namespace HelloWorld
{
  class Program
  {
      static void Main(string[] args)
      {
          using(WorkflowRuntime workflowRuntime = new WorkflowRuntime())
          {
              AutoResetEvent waitHandle = new AutoResetEvent(false);
              workflowRuntime.WorkflowCompleted += delegate(object sender, WorkflowCompletedEventArgs e) {waitHandle.Set();};
              workflowRuntime.WorkflowTerminated += delegate(object sender, WorkflowTerminatedEventArgs e)
              {
                  Console.WriteLine(e.Exception.Message);
                  waitHandle.Set();
              };

Malheureusement, je n'ai pas trouvé de script ou d'addin fournissant une solution "clé en main" de mise en forme du code, supportant la colorisation de mots clés et l'indentation. Je vous propose donc un petit bout de code Javascript permettant de faire cela.

Voici les objectifs du script de mise en forme:

Rechercher toutes les balises ayant l'attribut name comportant la valeur code et appliquer la fonction formatterElement

La fonction formatterElement recherche l'ensemble des mots clés fournit par le tableau motCles et rajoute autour la balise <span class="motcle"> mot clé </span>

Pour installer le script sur un blog de type Blogspot, copiez les styles CSS et les fonctions Javascript suivants quelque part dans la balise head de votre modèle.


<style type="text/css">
    div.code
    {
     background : #F0F0F0;
     border: 1px solid black;
     padding:5px;
     margin:5px;
    }
    span.motcle
    {
     color:Blue;
    }
</style>
<script type="text/javascript">
    var regexpEchampement = unescape("([ \(\)\{\},\t\n\r%3C%3E\[;&])");
    var motsCles = [
                    "public",
                    "private",
                    "protected",
                    "sealed",
                    "partial",
                    "static",
                    "class",
                    "struct",
                    "interface",
                    "using",
                    "namespace",
                    "object",
                    "string",
                    "int",
                    "bool",
                    "float",
                    "double",
                    "decimal",
                    "void",
                    "in",
                    "out",
                    "extern",
                    "true",
                    "false",
                    "new",
                    "if",
                    "for",
                    "foreach",
                    "throw",
                    "while",
                    "return",
                    "case",
                    "break",
                    "try",
                    "catch",
                    "finally",
                    "get",
                    "set",
                    "typeof",
                    "delegate"
                    ];

    function formatterElements(nameElement) {
        var codeElements = document.getElementsByName(nameElement);
        eval(unescape("for (var j = 0; j %3C codeElements.length; j++) { formatterElement(codeElements[j]); }"));
    }

    function formatterElement(element) {
        element.className = "code";

        var code = null;
        if ("outerHTML" in element) {
        }
        else {
            code = element.innerHTML;

            var loop = "for ( var i = 0 ; i %3C motsCles.length ; i++) { var reg = new RegExp(regexpEchampement + \"(\" + motsCles[i] + \")\" + regexpEchampement, \"g\"); code = code.replace(reg, unescape(\"%241%3Cspan%20class%3D%27motcle%27%3E%242%3C/span%3E%243\"));}";
            eval(unescape(loop));

            element.innerHTML = code;
        }
    }
</script>

Remarquez que le tableau motsCles contient pas mal de mots clés du langage C#. Libre à vous d'ajouter/supprimer des mots clés. De même, vous pouvez aussi modifier les 2 styles CSS.

Ensuite, ajoutez ce petit bout de javascript juste avant la fermeture de la balise body (</body>):
<script type="text/javascript">
formatterElements("code");
</script>

Voila le script est installé.
Pour l'utiliser, il suffit juste d'ajouter une balise pre et une balise div ou autre avec l'attribut name (ainsi que id="code", à cause de la méthode getElementByName d'IE qui regarde uniquement l'id des éléments) contenant la valeur code. Exemple :

<pre><div name="code" id="code" ></pre>
public Impersonation(string pIdentifiant, string pMotDePasse, string pDomaine )
{
_identifiant = pIdentifiant;
_motDePasse = pMotDePasse;
_domaine = pDomaine;
}
</div></pre>

Ce qui donne :


public Impersonation(string pIdentifiant, string pMotDePasse, string pDomaine )
{
    _identifiant = pIdentifiant;
    _motDePasse = pMotDePasse;
    _domaine = pDomaine;
}

EDIT : Pour l'instant, le script fonctionne à merveille sous Firefox, mais ne fonctionne pas vraiment sous IE 7/8. Cela vient du fait que toute affectation de la variable innerHtml d'un élément sous Internet Explorer normalise la chaine de caractères, et enlève l'ensemble tous les retours à la ligne et les espaces de plus de 2 caractères. Pour l'instant, je n'ai pas trouvé de contournement ...

1er article sur Developpez.com

2008-11-06T11:58:00.003+01:00

Ca y est !

Mon 1er article sur Developpez.com vient d'être publié hier.
Il traite de la génération de code dans Visual Studio 2008 et plus particulièrement de la création d'un Custom Tool. Celui-ci créé à partir d'un fichier XML (ici, un fichier de configuration Sharepoint) une classe associée. Cette dernière peut être utilisée pour récupérer facilement des GUID, chose très utile dans la programmation Sharepoint.

A noter que la classe est générée à l'aide de l'API CodeDom. Une autre alternative aurait été de générer la classe à partir d'une feuille XSLT.

En tout cas, merci à l'équipe de Developpez et surtout à Louis-Guillaume Morand, responsable de la section .Net, qui m'a aidé dans la publication et mon intégration dans l'équipe de rédaction du site.

Droits insuffisants, pensez Impersonation !

2008-11-05T13:29:00.021+01:00

Bien souvent, lorsque l'on développe une application web ou même parfois une application Windows (Winforms, WPF, ...), le compte Windows utilisé par l'application ne possède pas les droits suffisants pour effectuer des actions sur le système de fichier, le domaine, la base de données ou sur tout autre système.

Vous avez toujours la possibilité de modifier le compte utilisé. Par exemple, pour une application ASP.Net hébergé dans IIS, il est possible de changer le compte dans les paramètres du pool d'application. Cependant, ce n'est pas forcément une bonne solution. Cela peut même casser votre système d'authentification si celui-ci est de type Windows.

Il est aussi possible d'ajouter les droits nécessaires au compte utilisé par l'application. Mais cela est bien souvent maladroit. Le compte utilisé pour une application ASP.Net est par défaut "Service réseau". Il peut paraître indélicat d'ajouter des droits de d'ajout ou de suppression de dossier à ce compte. Une autre application web utilisant ce compte pourrait être détournée intentionnellement pour supprimer, modifier ou récupérer des données importantes ...

Une bonne solution est d'utiliser l'impersonation. Cela consiste à changer le compte utilisé pour exécuter la logique de votre application par un compte qui possède les droits nécessaires, c'est à dire un compte de service. Pour réaliser ceci, voici une petite classe utilitaire :



using System;
using System.Runtime.InteropServices;
using System.Security.Principal;
      
public class Impersonation
{
          [DllImport("advapi32", SetLastError = true)]
          private static extern bool LogonUser(string pUserName, string pDomaine, string pMotDePasse,
                                                                                                                                         int pLogonType, int pLogonProvider, out IntPtr pJeton);
          [DllImport("advapi32", CharSet = CharSet.Auto)]
          private static extern bool CloseHandle(IntPtr pHandle);
          private string _identifiant;
          private string _motDePasse;
          private string _domaine;
          private WindowsImpersonationContext _impContext;

          public Impersonation(string pIdentifiant, string pMotDePasse, string pDomaine )
          {
                     _identifiant = pIdentifiant;
                     _motDePasse = pMotDePasse;
                     _domaine = pDomaine;
          }

          public void Impersonifier()
          {
                     IntPtr handle = new IntPtr(0);
                     if (!LogonUser(_identifiant, _domaine, _motDePasse, 3, 0, out handle))
                                throw new Exception("Erreur d'authentification");
                     _impContext = new WindowsIdentity(handle).Impersonate();
              CloseHandle(handle);
          }

          public void Fermer()
          {
                     _impContext.Undo();
          }
}

Tout est articulé autour de la fonction LogonUser qui permet de récupérer un jeton d'authentification. Elle prend entre en paramètre l'identifiant, le mot de passe et le domaine d'un compte de domaine ou local (SAM).

Voici maintenant un petit exemple d'utilisation :



try
{
     Impersonation imp = new Impersonation("identifiant", "domaine.fr", "motdepasse}");
     imp.Impersonifier();
     try
     {
          // Votre code ncessitant des droits suprieurs
     }
     catch { }
     finally
     {
          imp.Fermer();
     }
}
catch { }

C# 4 et Visual Studio 2010 CTP en téléchargement

2008-10-29T11:51:00.006+01:00

A l'adresse suivante, vous trouverez une image virtuelle (Virtual PC 2007 SP1) où est installé Visual Studio 2010 !

La VM est découpée en plusieurs archives, d'un total de 8 Go. Une fois installée, l'image nécessite 75 Go d'espace libre, outch ! Mais bon, une fois passé ces petites contraintes, vous aurez l'immense privilège d'essayer C# 4 avec sa DLR, son nouveau mot clé dynamic et la covariance et controvariance sur les interfaces (mot clés in et out), et bien d'autres surprises.

Va falloir que je fasse de la place ...

Bon téléchargement.

Contenu de la PDC 2008

2008-10-28T23:19:00.006+01:00

La PDC 2008 (Professional Developers Conference) s'est déroulée du 25 au 28 octobre. Durant ces 4 jours intensifs, ont été présentés les produits et technologies suivantes :

C# 4.0 : La version 1.0 introduisait le code managé, la 2.0 les generiques, la 3.0 LinQ, la version 4.0 introduit la programmation dynamique. Le type des objets peut être connu juste à l'exécution, c'est à dire comme dans un langage de script (php, javascript, python, etc ...). Ceci est possible grâce à la DLR (Dynamic Language Runtime). Cela fait déjà plus d'un an que l'on en parle, et le plus célèbre des projets est l'implémentation du langage python, ironpython, dans la plateforme .Net. A l'instar de la CLR qui unifiait tous les langages de programmation statiques, la DLR unifie tous les langages dynamiques. Libre à vous de développer votre propre langage dynamique. C# 4.0 dispose d'un nouveau mot clé : dynamic. En substituant le type de votre objet par dynamic, le type de votre objet n'est connu qu'à l'exécution. dynamic est particulièrement utile pour manipuler des objets créés par des scripts. Cela permet de mélanger programmation statique et dynamique au même endroit. Le créateur du C# fait d'ailleurs une démonstration bluffante en copiant/collant un morceau de Javascript dans du C#. Après avoir modifié quelques mots clés (function, var), le code compile et fonctionne. Il est aussi possible de définir des paramètres optionnels dans les méthodes, et de les spécifier en fournissant le nom du paramètre en question. Grâce au support des types dynamiques, des paramètres optionnels et nommés, l'utilisation des objets COM est grandement simplifiée. Anders Hejlsberg part d'un exemple d'automation Excel, et simplifie petit à petit tous les appels aux objets et aux méthodes servant à piloter Excel. La covariance et controvariance a été amélioré, cela fonctionne maintenant avec les génériques de manière statique (mot clé in et out). En dernier lieu, le compilateur C# a été revu sous la forme d'un service pouvant être appelé simplement à partir d'un programme quelconque. Anders montre ainsi une console compilant et exécutant chaque ligne entrée. Le résultat est le même qu'avec un langage de script, le temps de compilation en plus bien sûr. Pour plus de détails, voici le lien de la conférence.

Visual Studio 10 : Toute l'interface de l'application est basée sur WPF. L'extensibilité a été fortement améliorée puisqu'il est possible d'intégrer des addins en copiant simplement l'assembly en question dans le répertoire prévu pour. Celui est pris en compte au prochain démarrage de l'IDE. Le designer pour Silverlight a aussi pris un coup de jeune et cela n'est pas un mal. Une gestion plus fine des fichiers de configuration a été mise en place, c'est à dire un par type de build (Debug, Release). D'ailleurs, voici l'url de la vidéo conférence.

Workflow Foundation : Une de mes briques préférées du Framework 3.0 a subit un petit lifting. Tout d'abord, l'actuel designer qui a la particularité d'être horiblement lent a été refait, ceci devant régler ce petit problème de performance. Les performances des workflows à l'exécution ont été largement améliorées. A noter aussi, la persistance des workflows est maintenant totalement personnalisable.

WPF, ASP.Net MVC, Surface SDK, Live Mesh (Bureau virtuel), Windows 7, Windows Azure : Je vous invite à aller voir le blog de Louis-Guillaume Morand pour plus de détails sur ces technologies et produits.

Workflow Foundation : Hello World

2008-10-21T11:32:00.014+02:00

Pour ne pas déroger à la tradition du HelloWorld, nous allons créer pour ce premier exemple, un workflow qui écrit HelloWorld et votre prénom dans la console. Cet exemple très simple a le mérite de décrire les étapes fondamentales du développement et de l'exécution d'un workflow séquentiel. On va donc voir comment créer un workflow avec un template de Visual Studio 2008 prêt à l'emploi. Nous verrons ensuite comment il est hébergé et exécuté grâce au moteur de workflow.

Dans un premier temps, créez d'abord un nouveau projet dans une nouvelle solution. Choisissez le template "Sequential Workflow Console Application", nommez le projet "HelloWorld" et la solution "HelloWorldWorkflow". Le projet créé est de type Console comme laisse présager le titre du template.

Ce template crée un workflow s'appelant Workflow1 dans un fichier de type cs (j'ai oublié de dire que le langage utilisé est le c#). En cliquant sur le petit plus, vous voyez apparaître le fichier Workflow1.designer.cs qui est le fichier généré par le designer de Workflow. Comme dans d'autres éditeurs fournis par Visual Studio, la classe Workflow1 est partielle (mot clé partial avant le nom de la classe), ce qui permet de définir dans 2 fichiers séparés, voir plus, la classe en question. Cliquez droit sur Workflow1.cs, et en choisissant View Code, vous verrez l'autre partie de la classe définissant le workflow.

Le template a aussi créé un fichier Program.cs qui contient le code nécessaire pour instancier et exécuter le workflow généré.

Sur ce, revenez sur le designer, ouvrez la Toolbox (boite à outils) et faites glisser l'activité Code qui est de type CodeActivity. Déposez là dans le workflow. Vous devriez avoir le résultat suivant :

Voila, nous venons d'insérer notre 1ere activité dans un workflow. Cette activité a pour but d'exécuter la logique métier que vous devez définir par l'intermédiaire d'une méthode. D'ailleurs, vous avez surement du remarquer le point d'exclamation dans le rond rouge en haut à droite de l'activité. Il signifie que justement, nous n'avons pas encore défini la méthode à exécuter et qu'il est nécessaire de le faire. Pour cela, double cliquez sur l'activité. Cela a pour effet de créer une méthode nommée "codeActivity1_ExecuteCode" et d'afficher le code de la classe Workflow1.cs. Dans l'autre partie de la classe générée par le designer, cela a instancié un délégué qui prend en argument la méthode précédemment créée et ce délégué est ajouté à l'événement ExecuteCode de l'activité.

Définissons le code de la méthode codeActivity1_ExecuteCode. Ce code va écrire dans la console "Hello World " suivi d'un nom qui sera passé en paramètre au workflow. Ajoutez d'abord la propriété Nom de type string comme cela :

public string Nom
{
get;
set;
}

Cette façon d'écrire une propriété, qui est une nouveauté du Framework 3.5, permet de générer à la fois l'accesseur (get), le mutateur (set) et le champ de type string associé. C'est un raccourci d'écriture qui est fort utile lorsque vous n'avez pas besoin de définir un comportement spécial pour le mutateur ou l’accesseur. Rajoutons ensuite la ligne suivante dans la méthode codeActivity1_ExecuteCode :

private void codeActivity1_ExecuteCode(object sender, EventArgs e)
{
Console.WriteLine("Hello World " + Nom);
}

Le workflow HelloWorld est terminé. Pour information, voici le code du workflow en entier (Workflow1.cs) :

using System;
using System.Workflow.Activities;

namespace HelloWorld
{
public sealed partial class Workflow1: SequentialWorkflowActivity
{
public string Nom
{
get;
set;
}

public Workflow1()
{
InitializeComponent();
}

private void codeActivity1_ExecuteCode(object sender, EventArgs e)
{
Console.WriteLine("Hello World " + Nom);
}
}
}

Tout d'abord le code généré dans la méthode Main qui est le point d'entrée de notre application console, sert à instancier et exécuter le workflow précédemment créé. Pour cela, nous devons d'abord instancier le moteur de workflow représenté par la classe System.Workflow.Runtime.WorkflowRuntime. Cette classe ou plutôt l'objet instancié de cette classe, fournit l'environnement d'exécution pour tous les workflows de l'application. Une seule instance de cette classe est autorisée par domaine d'application, comprenez par application pour simplifier. Il est bien évidemment possible de définir plusieurs domaines d'application dans une même application, mais ce n'est pas le sujet ici. Voici le code d'initialisation du moteur :

using(WorkflowRuntime workflowRuntime = new WorkflowRuntime())
{
}

L'instanciation du moteur est faite dans un bloc using (instanciation) {Suite d'instruction} car le moteur dérive de l'interface IDisposable, qui oblige la classe qui en hérite de définir une méthode Dispose. Celle-ci s'occupe de terminer l'exécution des workflows en cours et de libérer la mémoire utilisée. A la fin du bloc using, cette méthode est donc appelée implicitement. Toute nouvelle instruction prend place entre les accolades du using.

Poursuivons notre description. La ligne suivante déclare un objet de type System.Threading.AutoResetEvent et l'instancie :

AutoResetEvent waitHandle = new AutoResetEvent(false);

Cet objet est utile pour synchroniser 2 threads d'exécution. Il permet de stopper l'exécution d'un thread jusqu'à ce qu'un évènement particulier soit détecté, évènement déclenché dans un autre thread. Le thread déclenchant l'évènement le fait bien évidement au moment opportun, c'est-à-dire lorsqu'il a terminé ce qu'il a à faire.

Mais pourquoi avons-nous besoin d'un tel objet pour exécuter notre workflow HelloWorld ? Et bien, c'est simple. Le comportement par défaut du moteur de workflow est de créer un thread par workflow exécuté. Ce comportement est bien sûr modifiable, mais pour l'heure, nous ferons avec. Si nous exécutons notre workflow sans utiliser un objet AutoResetEvent, alors notre application instancie effectivement le workflow, le lance, ce qui crée un thread dédié où le workflow est exécuté. Cependant juste après la ligne lançant l'exécution du workflow, le flux d'exécution continuera sans attendre la fin du workflow, sortira ensuite du bloc using, ce qui appelera la méthode Dispose implicitement, qui aura pour effet de détruire l'instance du moteur et du workflow par la même occasion. Nous n'aurons même pas la chance de voir afficher notre "HelloWorld" dans la console. Avec un objet AutoResetEvent, cela nous permet d'attendre tranquillement la fin du workflow.

Définissons 2 délégués anonymes que l'on affectera à l'évènement WorkflowCompleted et WorkflowTerminated du moteur de workflow (ici workflowRuntime). Le 1er évènement est déclenché lorsqu'un workflow exécuté par le moteur se termine avec succès. L'autre, WorkflowTerminate, est déclenché lorsqu'un workflow se termine à cause d'une exception. Voici les 2 délégués :

workflowRuntime.WorkflowCompleted += delegate(object sender, WorkflowCompletedEventArgs e)
{
waitHandle.Set();
};

workflowRuntime.WorkflowTerminated += delegate(object sender, WorkflowTerminatedEventArgs e)
{
Console.WriteLine(e.Exception.Message);
waitHandle.Set();
};

Chacun d'eux exécute la méthode Set() de l'objet waitHandle. Cette instruction marche de pair avec la méthode WaitOne() du même objet. Comme expliqué plus haut, un workflow est exécuté dans son propre thread. Ainsi pour attendre la fin du workflow, nous utilisons la méthode WaitOne() qui attend que la méthode Set() soit exécutée dans un autre thread.

Les 2 délégués sont donc exécutés par le thread du workflow. Leur exécution permet de poursuivre l'éxecution de notre programme principal (bloquée jusqu'alors par WaitOne() de l'objet waitHandle).

Notez que le délégué associé à l'évènement WorkflowTerminated récupère l'erreur générée par le workflow et l'écrit dans la console.

A ce stade, il ne reste plus qu'à définir les arguments du workflow, c'est-à-dire le nom qui s'affichera à côté de "HelloWorld", de lancer le workflow et finalement d'attendre la fin de son exécution. Pour définir les arguments d'un workflow, WF permet d'utiliser une Hashtable ou Dictionnaire. Cette structure de données associe une valeur clé (ici de type string) avec un objet et cette association de données définie un élément du dictionnaire. Voici le code pour définir le paramètre de notre workflow :

Dictionary<string,object> arguments = new Dictionary<string,object>();
arguments.Add("Nom", "John Connor");

Il est possible de remplacer le nom ci-dessus par l'un de votre choix, ceci n'a aucune incidence sur le bon fonctionnement du workflow. Lors de la définition de notre workflow, nous avons défini une propriété Nom dans la classe partielle du workflow. La clé de notre argument dans le dictionnaire a le même nom que cette propriété. En fait, lorsque l'on passe le dictionnaire au moteur pour instancier notre workflow, celui-ci va, après avoir instancié le workflow, chercher, via la réflexion, la propriété du workflow s'appelant exactement "Nom" et va lui donner la valeur, ici "John Connor" en la castant, vu que c'est un objet dans le dictionnaire.

Il ne reste plus qu'à instancier le workflow et le lancer avec les 2 instructions suivantes :

WorkflowInstance instance = workflowRuntime.CreateWorkflow(typeof(HelloWorld.Workflow1),arguments);
instance.Start();

La méthode CreateWorkflow prend en argument le type du workflow et le dictionnaire définissant les arguments. Elle renvoie un objet de type WorkflowInstance qui contient la méthode Start() permettant d'exécuter le workflow.

Finalement, ajoutez les 2 lignes suivantes pour attendre la fin d'exécution du workflow et de laisser le choix à l'utilisateur de fermer le programme.

waitHandle.WaitOne();
Console.ReadKey();

Si tout s'est bien passé, voici l'affichage que vous devriez avoir après avoir compilé et lancé le projet :

Pour une meilleure vision du code nécessaire à l'instanciation et l'exécution d'un workflow, voici l'intégralité du code :

using System;
using System.Threading;
using System.Workflow.Runtime;
using System.Collections.Generic;

namespace HelloWorld
{
class Program
{
static void Main(string[] args)
{
using(WorkflowRuntime workflowRuntime = new WorkflowRuntime())
{
AutoResetEvent waitHandle = new AutoResetEvent(false);
workflowRuntime.WorkflowCompleted += delegate(object sender, WorkflowCompletedEventArgs e) {waitHandle.Set();};
workflowRuntime.WorkflowTerminated += delegate(object sender, WorkflowTerminatedEventArgs e)
{
Console.WriteLine(e.Exception.Message);
waitHandle.Set();
};

Dictionary<string,object> arguments = new Dictionary<string,object>();
arguments.Add("Nom", "John Connor");

WorkflowInstance instance = workflowRuntime.CreateWorkflow(typeof(HelloWorld.Workflow1),arguments);
instance.Start();

waitHandle.WaitOne();

Console.ReadKey();
}
}
}
}

Indexation MOSS : Faites attention à la page par défaut d'une collection de site

2008-10-16T11:09:00.009+02:00

Actuellement, je travaille sur un portail intranet basé sur Sharepoint MOSS. Etant en phase d'intégration, je corrige les quelques bugs restants. L'un d'entre eux m'a particulièrement surpris concernant l'indexation d'une collection de site. Celle-ci s'arrêtait au bout de 3 items "crawlés", alors que la collection contient plus de 800 éléments à indexer.

Après une petite recherche dans les logs applicatifs du serveur, je suis tombé sur une erreur de type Warning, ASP.NET 2.0.50727.0, WebEvent :

Je remarque que dans les Request Information la page d'accueil (page par défaut) de la collection de site renvoie une exception de type NullReferenceException. Pourtant, dans la définition des sources à indexer, seuls 2 sous sites ont été spécifiés. La page par défaut ne devrait pas être indexée. Pour vérifier que la page par défaut de la collection de site est en cause, j'ai donc spécifié une autre page par défaut grace à une page Layout uniquement accessible par URL : [url collection de site]/_Layouts/AreaWelcomePage.aspx.

Après avoir effectuer la manipulation et relancer le crawl, tout est rentré dans l'ordre. J'ai donc du modifier la page par défaut en éditant un script C# codé de manière inline dans la page par défaut de la collection de site.

Moralité, faites attention à la page par défaut de votre collection de sites si vous souhaitez indexer le contenu des sous sites.

Qu'est ce qu'un workflow ?

2008-10-08T13:17:00.004+02:00

Pour répondre à cette question, je vais faire l'analogie avec le code d'un développeur. Lorsque l'on développe, on définit le plus souvent une suite d'opérations ou de tâches. Cela peut être une insertion dans un journal d'événements ou dans une base de données. Ensuite, on ordonne ces opérations avec des instructions qui contrôlent le flux de notre programme. Par exemple, on utilise l'instruction :

If (condition)
{Liste d'opération 1}
else {Liste d'opération 2}

ou un bloc :

While (Condition)
{Liste d'opérations}

pour traiter des données en boucle.

Chaque décision dans le code, que ce soit en C#, Java, C/C++, Javascript etc ..., est matérialisée par des conditions. Tout code source possède 3 types d'instruction:

Les instructions d'exécution qui peuvent être une écriture dans une base de données ou encore dans un journal d'évènements, l'envoi d'un mail, ou plus généralement toute instruction qui exécute une action.
Les instructions définissant le flux d'exécution comme le bloc if (condition) {instructions} else {instructions}. Ce sont toutes les instructions qui ont une influence sur le flux d'exécution du programme.
Les règles qui définissent les conditions dans les flux d'exécution.

Voici un exemple montrant les 3 types les 3 types d'instruction:

Les concepteurs de Workflow Foundation ont identifié ces 3 concepts et les ont intégrés dans Workflow Foundation. Un workflow n'est rien d'autre qu'une suite d'instructions d'exécution représentée par des activités (Custom Activity, Code Activity, InvokeWebService, etc…). Ces instructions d'exécution ou activités sont elles-mêmes comprises dans des activités définissant le flux d'exécution du programme (IfElseActivity, WhileActivity, ParallelActivity, ReplicatorActivity, etc…). Pour définir les conditions dans les activités définissant le flux d'exécution, on met en place des règles (rules en anglais). Pour illustrer cela, voici un workflow reprenant la même logique que l'exemple précédent :

Premièrement, le workflow est représenté de manière graphique. Les deux exemples réalisent exactement la même chose. Cependant, dans le premier exemple, tout a été défini avec un langage textuel qui est le C# alors que dans le deuxième, tout a été quasiment définit de manière graphique en utilisant le drag'n drop et la fenêtre de propriété de Visual Studio 2008.
Aujourd'hui, c'est dans l'air du temps d'utiliser ce que l'on appelle des langages graphiques ou des DSL (Domain Specific Language). Le plus célèbre d'entre eux est le designer de classes intégré dans toutes les éditions de Visual Studio. Workflow Foundation propose ainsi de définir votre propre langage graphique pour définir les workflows. Pour cela, nous avons à notre disposition un ensemble d'activités que l'on peut glisser et déplacer dans la fenêtre définissant le workflow. Voici un aperçu de la Toolbox regroupant les différentes activités fournies par WF :

Il est aussi possible de définir un workflow par le code, en instanciant les bons objets, ou avec du XAML (rebaptisé XOML dans WF, pour le différencier du XAML de WPF). Le XAML est un langage basé sur XML permettant d'instancier et de paramétrer des objets.
Lorsqu'on crée un nouveau workflow, nous avons le choix avec 2 implémentations de workflow :

Workflow basé sur du code uniquement
Workflow basé sur du XAML avec un fichier de code associé

Théoriquement, il est aussi possible définir un workflow basé uniquement sur du XAML en supprimant le fichier de code associé, Visual Studio 2005 ou 2008 ne propose pas ce template. L'intérêt principal d'un workflow définit uniquement en XAML, est que l'on peut le modifier à la main ou via un éditeur spécialisé sans avoir besoin de recompiler l'application. Cela laisse penser qu'il est possible développer des applications avec des workflows, et que votre client pourra via un éditeur de workflow, modifier par la suite le comportement de son programme en éditant lui-même ses workflows. Bien sûr, il devra avoir une connaissance du vocabulaire métier défini dans le workflow, mais comme celui-ci est la matérialisation d'un processus de l'entreprise, cela devrait lui être familier. Dans tous les cas, c'est beaucoup plus simple et plus réaliste que de modifier du code et de le recompiler.
Une autre différence fondamentale lorsqu'on utilise WF est que la logique définissant ce que l'on fait est séparée de la logique qui définit quand on le fait. C'est-à-dire que l'on peut changer toute la logique de séquencement ou d'ordonnancement d'un workflow sans affecter les instructions d'exécution. Pour cela, on sélectionne la ou les activités voulues et on les déplace à l'endroit souhaité dans le workflow. Avec un langage textuel, cela se résumerai à un ensemble de couper/coller quelque peu hasardeux et pas toujours très simple à réaliser.
Comme la logique d'ordonnancement est définie de manière déclarative et qu'en fait chaque activité correspond à une classe, il est tout à fait possible de modifier à l'exécution, c'est-à-dire dynamiquement, un workflow. Par exemple, on peut rajouter de nouvelles instructions d'exécution ou des instructions définissant le flux d'exécution à un endroit donné. Il suffit simplement d'instancier les activités voulues, de les paramétrer et de les insérer là où on le souhaite. Comparé à un langage textuel, cela pourrait être synonyme d'injection de code (via de la POA par exemple), ce qui est quand même bien plus complexe à réaliser.

Utiliser les Custom Tools dans Visual Studio

2008-10-05T19:01:00.007+02:00

Alors déjà, qu'est ce qu'un Custom Tool ?
C'est un utilitaire sous forme de librairie (dll) qu'utilise Visual Studio afin de générer quelque chose, généralement des classes, à partir d'un fichier en entrée. Chaque fichier présent dans une solution Visual Studio (2003,2005 et 2008) propose dans sa fenêtre de propriété un champ Custom Tool.

Sur un fichier de ressources de type resx, le Custom Tool ResXFileCodeGenerator est défini d'office. Son rôle est de générer une classe contenant le code pour accéder aux différentes ressouces déclarées dans le fichier XML. Voici une liste regroupant les plus populaires :

MSDiscoCodeGenerator : Génère une classe proxy permettant d'accéder simplement à un web service à partir de son fichier wsdl
WCF Proxy Generator : A partir d'un fichier .svcmap, ce custom tool génère la classe d'accès au service
SettingsSingleFileGenerator et ResXFileCodeGenerator : Génère une classe proxy vers un fichier de configuration ou de ressources
EntityModelCodeGenerator : Génère l'ensemble des classes d'accès aux données (Entity Framework) à partir d'un fichier edmx
MSLinqToSQLGenerator : A l'instar de EntityModelCodeGenerator, ce custom tool s'occupe du fichier XML (.dbml) créé par le designer de LinQ to SQL.
MSDataSetGenerator : Créé un ensemble de fichier XML et de classes définissant un Dataset, à partir d'un fichier XSD

Les Custom Tools permettent de gagner un temps conséquent (plusieurs milliers de lignes de code peuvent être générées d'une passe) et garantissent une certaine qualité dans le code produit. Il est à noter que cela fonctionne que dans un seul sens (unidirectionnel). Modifiez un fichier généré par un Custom Tool et celui-ci sera écrasé à la prochaine génération.

Il est aussi intéressant de savoir que l'on peut redéfinir le Custom Tool attaché à n'importe quel fichier. Du coup, si le code créé par un Custom Tool ne vous plait pas, rien ne vous empêche de créer le votre et de l'attacher au fichier source. Sur le site suivant, vous trouverez une démonstration avec le WCF Proxy Generator : http://blogs.msdn.com/pedram/archive/2007/08/10/customising-wcf-proxy-generation-in-visual-studio-2008.aspx.

Alors comment savoir si vous avez besoin de créer votre propre Custom Tool ? Et bien, si vous avez un ou plusieurs fichiers XML dans vos projets C# ou VB .Net, et que vous devez créer du code pour accéder aux informations stockées dedans, un Custom Tool adapté vous permettra de vous passer de cette tâche un peu fastidieuse. Je les ai d'ailleurs utilisés pour un projet Sharepoint. Une solution typique WSS ou MOSS contient bien souvent un nombre impressionnant de fichiers XML (features, fields, ONET.XML, etc ...), et il est souvent utile de pouvoir accéder facilement à certaines de leurs informations.

Voici quelques liens si vous souhaitez créer votre propre Custom Tool :

Pour Visual Studio 2005 & 2008 en français, en VB & C# : http://gilles.tourreau.fr/dotnet/visual_studio/vs2005_2008_creation_dun_outil_personnalise_custom_tool.html
Pour Visual Studio 2005 en Anglais : http://blogs.conchango.com/pauloreichert/archive/2005/05/21/1459.aspx

Pourquoi développer des workflows avec Workflow Foundation ?

2008-05-12T13:46:00.002+02:00

Tout d'abord, Workflow Foundation est un Framework permettant de réaliser des workflows tout en respectant une bonne productivité. Dorénavant, si vous pensez créer des workflows dans vos prochains projets, il est clair que vous devez penser à Workflow Foundation, surtout si vous êtes familier du Framework .Net. Si vous êtes issu du monde J2EE, PHP ou autre, il est tout à fait possible et Microsoft a travaillé dessus, de mettre en place un service quelconque, qui expose par des méthodes vos propres workflows. Tout ceci est réalisé avec un minimum d'effort si bien sûr vous disposez de Visual Studio 2005 ou 2008.

WF propose un ensemble d'outils cohérent pour concevoir vos workflows. L'investissement requis pour comprendre WF et mettre en place un workflow est vite rentabilisé. L'éditeur de workflow fourni, permet un développement visuel et non plus textuel de vos processus. Cela se résume le plus souvent à du glisser/déplacer et à de la configuration de propriétés. Il est alors très facile à comprendre que cela augmente la maintenabilité de vos workflows.

Cet environnement graphique permet d'exposer et de discuter de vos workflows avec le client. En effet, un graphique est bien plus parlant que du texte et rien que penser à montrer du code à un client est complètement absurde. Un processus conçu visuellement avec WF est vite compréhensible par quiconque comprenant le vocabulaire métier exposé.

Lorsque vous développez vos propres workflows, vous êtes souvent amené à créer des custom activity (activités personnalisées). Ces composants ont la particularité d'être fortement réutilisables, d'une part dans un même projet mais aussi entre projets (du moment qu'ils sont indépendants). Il est tout à fait envisageable de créer une bibliothèque d'activité, que chaque développeur et architecte utilisera et alimentera.

Le Framework est fourni avec une suite d'activités standards qui couvrent un ensemble important de cas conventionnels. D'une part, ces activités vous aiguillent dans la conception de vos workflows, et d'autre part vous bénéficiez de l'expérience de Microsoft dans la matérialisation de vos processus. De plus, avec le service de persistance fourni, qui permet le stockage de vos workflows en base de données, cela a pour effet d'augmenter la fiabilité et les performances de vos applications. Le service de trace aussi fourni, permet de suivre l'exécution de vos workflows en quasi temps réel.

Premier Billet !! Et surement pas le dernier :)

2008-04-28T21:25:00.001+02:00

Et voila, j'ai enfin décidé d'ouvrir un blog pour discuter de développement, et surtout de .Net ^^.