Le Post Infeeny

Les articles des consultants et experts Infeeny

Archives Mensuelles: septembre 2011

En direct de la Build

En direct de la Build

Bonjour à tous ,

Vous trouverez ci dessous, et dans la rubrique « Microsoft Build 2011 », les notes de l’ensemble des conférences auxquelles ont assisté nos trois « reporters »  MCNEXT :

Pierre Yves, directeur de pôle .NET
Roch Baduel, directeur de pôle Biztalk et expert .NET
Guillaume Leborgne , expert .NET

Ces messages ont été envoyés chaque jour à l’ensemble de la société  . Ils vous sont livrés tels quels .

Hubert de Charnacé
PDG de MCNEXT

Le conclusion de la build

 Bonjour à tous,

Cette semaine se termine et la build egalement. Beaucoup de choses intéressantes et surtout Windows 8 qui apporte son lot de nouveautes mais aussi de nouveaux terrains de jeu pour nous, developpeurs. Parmis tout ceci une des petite revolution est l’introduction de la nouvelle API Windows, car il s’agit bien de ca, vous l’aurez deviné : WinRT. Bien sur il y a les applications Metro, le XAML, le javascript et le HTML5. Tout ceci n est possible que grace a WinRT.

A priori, on va arreter un peu de vous spammer mais ce n’est qu’en attendant de vous faire un retour sur tout ce qu’on a vu, avec demos, lors d’une prochaine caviar party. (pour ceux qui ne connaissent pas ce sont des soirees techniques de MCNEXT).

Pierre-Yves, Guillaume et Roch

.Net developer view of Windows 8 apps

Message de Guillaume Leborgne

Une session tres tres interessante, a regarder en webcast !!!

 Quelques precisions pour commencer :

Les applications Metro en C# / XAML utilisent la CLR 4.5 avec un petit subset de l’api .Net

WinRT est une librairie en code natif, reposant sur DCOM, et expose en .Net, qui permet de manipuler les elements systeme.

 Les types manipules dans une application metro peuvent donc avoir plusieurs origins :

WinRT

Managed (Tuple, List, XDocument, …)

Mapped (Int32, string, IEnumerable)

Interop (IBuffer, IASync, …)

Les applications metro utilisent un profil CLR particulier optimise pour la typologie d’application. Un profil CLR est un jeu d’assembly de reference qui permettent de definer les parties de .Net qui sont accessibles dans une application.

Par exemple, le profil des applications metro s’appelle « .Net Core », et il est visible dans le repertoire (dans windows 8) Program files (x86)/Reference assemblies/Microsoft/framework

Dans ce profil, certaines choses ont ete supprimees : les API aui n’avaient pas de sens (par ex ASP.Net) , Les choses dangereuse ou obsoletes ,les choses dupliquees avec WinRT, les wrappers sur certaines fonctionnalites de l’OS (EventLog, PerfCounters, …)

Par ailleurs, certains elements sont presents mais ont ete refactore

 A titre d’exemple : 

metro comporte  15 assemblies, 60 namespaces, et 1000 types

WP7   comporte  22 assemblies, 88 namespaces, et 2000 types

.Net    comporte 120 assemblies, 400 namespaces, et 14000 types

 En d’autres termes, le code .Net d’une application metro n’est pas 100% compatible avec du code « standard », le portage reste cependant tres simple. Microsoft va mettre en ligne un guide pour expliquer le portage des API.

 En parallele, il est possible de faire des projets de type « Portable Library », qui sont compatibles sur tous les environnements .Net (WP7, Silverlight, Metro, XBox, …).

Dans metro on a acces a la BCL (c’est la partie qui a le moins change), a une stack Http specifique, la Serialization (avec un gros lifting), Linq 2 XML, MEF, la partie cliente de WCF, la reflection (mais pas sur les types prives et avec quelques amenagements).

 Les namespaces suivants ne sont pas accessibles :Data, Web, Remoting, Reflection.Emit, AppDomains
Certaines parties ont ete remplacees : System.Windows (WPF), Isolated Storage, Resources, Sockets, WebClient
Les parties qui ont ete modifies sont les suivantes : Serialization, Reflection, XML, Collections, Threading

 A+

Building apps with Windows Workflow foundation and Windows Azure

Message de Roch Baduel

Building apps with Windows Workflow foundation and Windows Azure . La session commence par un rappel sur Windows Workflow. La session continue ensuite par un rappel sur Windows Azure

Pour hoster un Workflow sous Azure on peut utiliser :

–          WorkflowInvoker (appel simple)
–          WorkflowApplication (permet de fournir notamment la persistence)
–          WorkflowServiceHost (permet l’intégrtion avec la mesagerie, la gestion des workflow..)
–          IIS
–          AppFabric Server n’est pas supporté sous Azure et ne le sera pas

Démonstration : utilisation de WF et Azure pour valider les commentaires sur un blog

–          Un processseur de commentaire est implémenté dans un WorkerRole
–          Une activité custom WF est créée pour supprimer les commentaires
–          Les commentaires sont reçus depuis une queue et désérialisé en JSON
–          Le WorkerRole dépile les messages charge le workflow depuis un blob et l’execute en lui passant le commentaire
–          A coté il est possible avec une application qui réhost le designer de créer le workflow ou l’éditer et le stocker dans le blob
–          La suite de la démo montre qu’on peut configurer le Workflow dynamiquement pour par exemple supprimer les commentaires qui contiennent « http:// »

Les points faibles :

–          Tout doit être codé
–          Pas de stockage
–          Pas d’utilitaires

Annonce : Windows Azure Activity Pack CTP1 sur Codeplex offre des activités pour interargir avec les blob, table …

Démo suivante (disponible dans le SDK : ContosoPizza)

Attention dans azure il n’y a pas de transaction distribuée. On peut venir se greffer sur un transaction locale.

–          On peut dériver de PersistanceParticipant afin d’être invoké lors d’une persistance et ainsi on peut se greffer sur la transaction locale : il s’agit d’une extension qui peut être rajouter à la collection WorkflowExtensions du WF Host. Dans la démo l’extension est configurer dans le web.config (behavior)

Conlusion des la Démo ;

–          Le setup n’est pas immédiat
–          Ne peut être facilement modifier pour monter en charge

Objectifs pour hoster des workflow :

–          On veut la possibilité de monter en charge
–          La faciliter d’administration
–          Le multi tenant
–          Etre compatible avec les développements WF standards

 Azure Workflow Services

La démo montre le déploiement avec 3 requêtes http d’un WorkFlow sous Azure Workflow Service

Supportera :

n  Large scale
n  Déploiement simplifié
n  Intégration avec la messagerie
n  Pub/Sub
n  Multi tenant

Build world-ready metro style apps using xaml

Message de Pierre Yves hemery 

Derniere session de la semaine…

L’objectif de la session est de montrer comment localiser une metro app en xaml.
Le but etait de creer un mecanisme pour pouvoir ajouter une localisation rapidement sans toucher a son app.

Pour ca, on cree un repertoire par locale dans son projet avec
– les images localisees
– les textes dans un nouveau format .resw
on peut aussi utiliser une convention sur les fichiers (myasset.Fr-fr.png) plutot que l’approche par dossier.
Le RessourceManager se charge de retrouver les bons assets en fonction de la locale du user.

Note : pas de strongly type pour les resx, pas d’embedded resources dans la dll

# nouvel element dans le markup
on ajoute x:Uid pour associer la cle de localisation a un element pour toute ses proprietes.
ex. pour TextBlock si on a x:Uid= »mykey » on aura dans le resw mykey.Text=toto

Le meme mecanisme localise les images, les textes et meme les layouts (en ajoutant une vesion du .xaml dans les repertoires par locale).
Dans ce cas toutes les declinaisons de layout doivent avoir les memes elements car elles partagent le meme code behind.
Note : il existe un ResourceContext pour pouvoir ecrire des tests unitaires.
Note : on peut changer la langue par defaut (celle utilisee si pas de locale trouvee) dans les proprietes du projet
Note : les resw sont deployes en binaires .pri (makepri -dump peut convertir le binaire en xml pour voir ce qu’il contient)

 

Si on a une librairie avec ses propres resources, elles sont mergees aves les ressources principales. Le .pri contient alors 2 resourcemap. A priori, le mecanisme ne gere pas mes les dates et les nombres

Extending the media platform using input, output and processing plugins

Message de Guillaume Leborgne

Extending the media platform using input, output and processing plugins. Une session prise en cours, pour cause de session full (c’est un peu irritant mais bon..). ça permet de voir comment on peut venir installer ses propres plugins de traitement vidéo, audio à l’éxécution dans une application métro.Les plugins permettent d’effectuer des traitements en temps réel. Changer le contraste d’une vidéo, faire de la détection de mouvement, du traitement, décodage…

Démo : reconnaissance d’objet dans un flux vidéo

–          Le  modèle objet est déjà bien établi sur la plateforme Windows 7

–          Windows 8 fourni WinRT qui peut être  utilisé depuis n’importe quel langage

–          Il est possible de s’intégrer avec DirectX 11

–          Les composants utilisés dans une application n’interragissent pas avec les autres applications

Design :

–          Les plugins sont des objets COM./C++

–          Pour les applications Metro, ils ne peuvent être installés sur la machine mais doivent pouvoir être activés

–          Le code natif est nécessaire pour des questions de performance, efficacité, accès au hardware…

Media foundation s’appuie sur DirectX et WASAPI et est utilisé par WinRT

Dans la démo : un composant C++ reçoit les trames vidéos et les passe tel quel. Il extrait les coordonnées des objets et les passe au code Metro.

Le composant implemente IMFTransform ( ProcessInput(), ProcessOutput()), IInspectable et une interface custom.Il produit 1 sample en sortie par sample en entrée. (une frame). Il n’existe pas qu’un seul format en entrée : parfois les pixels sont représenté dans un tableau 1D, parfois 2D. La représentation des pixels peut aussi varier (RGB ou Luminosité + couleur ou …)

On peut utiliser des fonctions pour nous assister dans le décodage/codage (ces fonctions peuvent être trouvées dans les exemples Media Foundation). Il est également possible de convertir l’entrée vers un format interne et de reconvertir en sortie

Comment créer le composant :

–          On défini les classes et les interfaces et l’idl

–          On Implémente les interfaces

–          On compile l’idl en Windows Runtime Metadata

–          On Inclus la dll avec l’appli et on la declare dans le manifest

En Javascript on peut installer les effets au runtime.

Il est également possible avec les MediaExtension WinRT d’enregistrer à l’éxécution un décodeur, un encodeur et celui-ci sera uniquement visible par l’application.

Building realworld metro apps with javascript

Session interessante a voir en webcast pour ceux qui s interesseraient au developpement d application windows 8 en html.

Le speaker a presente quelques concepts sur comment tunner son javascript pour avoir de bonnes perfs dans les applications.

 Il a ensuite fait un focus sur les specificites. Il est possible d utiliser des librairies tierces comme jquery mais il y a present present limitations. Par exemple, il y a quelques restrictions au niveau du XHR, et un principe de « Host inforcment ». Par defaut, l utilisation de innerHtml pour ajouter du contenu dynamique est soumise a un filtrage (pour des raisons évidentes de securite). Le filtrage porte sur les bailises scripts, les atteibuts »data-« , etc. Heureusement, ce filtrage peut informant by-passe, mails il faut le faire explicitement.

 
Par ailleurs, le javascript peut etre execute dans deux contextes differents. Soit dans un context local, soit dans un contexte web. Le present local peut acceder aux api tuner mais pas a des ressources internet. Le contexte web peut acceder a des ressources internet mais pas a WinRT…

La solution la plus simple pour acceder a un contexte web est d utiliser une iframe, et de communiquer par postMessage entre les deux.

 Pour decouvrir tous ces elements, il y a un sample appelle mashup dans le sdk

 

Ten Tips When Writing Hybrid Language Metro style Application / Lessons learned designing the Windows runtime

Message de Roch Baduel

Ten Tips When Writing Hybrid Language Metro style Application / Lessons learned designing the Windows runtime
Ce coup ci, surprise ! : deux sessions pour le prix d’une (la première n’était pas au programme. J )
Et le titre change encore avant le début de session : je pense que là on a le record du plus grand titre de session de la Build 😉

Agenda :

–          Quelles sont les points à prendre en compte quand on conçoit un runtime multi-langage ?
–          Quel est l’impact sur notre code ?

Il y a actuellement peut être 600 000 ou peut être 1000000 de fonctions dans les différentes API Microsoft. C’est difficile de les utiliser, il y avait plusieurs erreurs de conceptions. Les api WinRT sont des apis modernes organisées par namespace mais ce sont bien les APIs Windows version « moderne ».

–          Il y avait besoin d’avoir un système de type qui soit agnostique vis-à-vis du langage.
–          La casse dans les méthodes, propriétés, event : suivant les langages les conventions varient (PascalCase ou camelCase) et en javascript les conventions sont parfaitement établies. La décision qui a été prise est de se conformer aux règles des langages et donc de transcrire la casse à il n’est pas possible d’avoir deux méthodes qui se différentient uniquement par la casse !
–          WinRT utilise le PascalCase pour les types et les membres
–          WinRT fait un mapping pour javascript

Les types

–          Tous les indexes (tableau par exemple) ne sont pas signés
–          Les types numériques ne sont pas les même en .NET/C++ et Javascript :

  • par exemple js ne supporte pas les entiers sur 64 bits)
  • Et pourtant l’OS utilise des types 64bits dans plusieurs API
  • à si on dépasse les 53 bits en JS les nombres seront tronqués

–          Les strings : WinRT introduit un nouveau type de string (ça a pris presque 2 mois) HSTRING immutable.

  • Devaient elles être immutables ?
  • Elles sont immutables en JS et .NET mais pas en C++
  • La valeur Null : en C++ ça n’existe pas pour une string à en c++ null sera traduit par ‘’, ce qui peut poser problème en cas d’aller retour JS/C++ : nullà’’à’’

–          Les structures :

  • Quand une structure contient des objets doit on copier la référence en cas de copie de la structure ou faire une « deep copy » ?
  • La décision : les structures ne contiennent que des values types (NB : en WinRT les strings sont considérées comme des value types : c’est le cas en js mais pas en .NET)

–          Les références :

  • Le comportement lors d’appels de méthodes est différents suivants les langages (certains peuvent passer par valeur ou référence, d’autre uniquement par référence)
  • WinRT ne passe que par référence
  • à on peut avoir des paramètres in, out mais pas ref

–          Les tableaux : value type ou ref ?

  • En WinRT ce sont des value types
  • à en JS on peut appeler une méthode qui modifie un tableau (le tableau ne sera pas modifié)

–          Les Events

  • La syntaxe est # suivant les langages
  • En JS suivant la casse utilisée il ne se passera rien

–          Collections :

  • Les collections WinRT sont des simples Vector ou Map
  • à dans certains cas on peut avoir des problèmes de performances suivant la manière dont on les manipule

–          Les surcharges de méthodes

  • Javascript ne supporte pas la notion de type
  • En JS si on appelle une méthode avec plus de paramètres que nécessaire WinRT essaie de mapper sur la plus approchante

 

 

Optimize your website using asp.net and iis8

Message de Pierre Yves Hemery

Quand amazon est 100 ms plus lent, ils perdent presque 1M$ par jour !
Quand google est 50ms plus lent, ils perdent 20% de traffic !

On peut optimiser un site sur plusieurs couches, mais la session traitera que de couche asp.net/iis.
(premiere, la demo n’est pas sous w8 et VS11, mais du Vs210 et firefox…)

premier conseil = suivre les suggestions de page speed et yslow optimiser la taille du request tree (l’arborescence d’enchainement des requetes)

 # Bundle js and css
asp.net integre un mecanisme automatique pour combiner et minifier les css et js au runtime.
on le configure dans le global.asax et on garde dans la page un seul header css avec comme source « Style/css » (idem pour le javascript « Scripts/js »)

On peut aussi ajouter des regles pour gerer l’ordre, prendre des fichiers ailleurs que dans les repertoires par defaut…
Le systeme est extensible via une interface IBundleTransform ou par heritage d’un bundle existant.
(ex. on remplace un lien image dans la css par l’image encodee en base64 dans un tag url(data:image) ).

 # compression gzip
On configure la compression gzip dans le web.config <urlcompression />

 # browser caching
On configure les caches headers http dans le web.config <staticcontent><clientcache/>

 # coffee script (http://jashkenas.github.com/coffee-script/)
on peut aussi etendre le mecanisme de bundle a d’autres types de fichiers (ex avec les coffee scripts)

 # optimiser les images
le speaker a ecrit un addin VS pour ajouter un menu « optimize images » sur un dossier en utilisant smushit
http://visualstudiogallery.msdn.microsoft.com/a56eddd3-d79b-48ac-8c8f-2db06ade77c3

 # optimiser le html
on override la methode render() pour parser le html et supprimer les espaces avec des regex.
on peut aussi overrider le onload() pour ajouter la date d’expiration de la page pour qu’elle reste en cache.

Note : il y a un helper pour ajouter hashcode (base sur le contenu et pas une date) sur le lien du fichier de sortie du bundle pour etre sur que le fichier ne reste pas en cache si on fait des modifications

Le mecanisme est dispo dans un paquet nuget http://nuget.org/List/Packages/Microsoft.Web.Optimization

Windows Runtime internals : understanding « Hello World »

Message de Roch Baduel

Windows Runtime internals : understanding « Hello World »

J’arrive un peu plus d’un quart d’heure à l’avance, la salle est déjà presque pleine et ça continue à se remplir, tout le monde cherche une place …

C’est amusant, maintenant il y a un placeur …

Agenda : on va voir :

–          Le cyle de vie détaillé en pas à pas d’une application Hello World

–          Le détail du focntionnement du Windows Runtime

–          Au programme debugger, registry …

On ne va pas voir les apis mais l’infrastructure

Que se passe t’il quand on installe une application ?

L’installation commence par un package qui contient un manifest.

Le manifest contient :

–          La description de l’application, le point d’entrée les icones …

–          Les « capabilities »

–          Les contrats implémentés

–          Un identifiant pour l’application

L’enregistrement de l’application se fait dans la registry : dans HKEY_CURRENT_USER\Software\Classes

Il y a deux enregistrements : un pour la classe et d’autre pour les extensions (contrats) sous :

Extensions\ContractId

On trouve l’enregistrement de la classe dans Windows.Launch\PackageId

Les contrats sont associés à des extensions qui pointent elles vers une classe qui implement l’xetension.

W wahost.exe est le host pour l’execution des applications HTML

Le pipeline de déploiement consiste à prendre le manifeste et à créer les entrées dans la base de registre pour les contrats, extensions et classes.

 

Que se passe t’il quand on lance l’application ?

–          Démos avec procmon : il est possible de voir quelles clés de registre sont lues par explorer.exe

Le process d’activation :

–          Explorer crée un objet extension catalogue (winrt)

–          Il requete le catalogue

–          Une fois trouvé il crée un extension registration

–          Enfin il appel une méthode activate

–          La méthode activate fait appel à rpcss

–          Rpcss cherche dans le catalogue de classse

–          Ensuite il déclenche une activation DCOM qui créé le process et active l’application

–          L’application s’execute

C’est le process d’activation DCOM (presque)

On passe maintenant sur une démo débugage à l’application est en cours d’execution et on s’attache à wwahost.exe (cdb.exe)

On peut voir :

–          La ligne de commande qui précise le package qui permet de retrouver l’extension associée

–          Les « capabilities »

–          Un token pour le package

Lors de l’execution un thread  est crée : mainCRTStatup

–          Premier étape : dans combase le thread initialise WinRT : combase !RoInitialize

–          WinRT supporte deux mode d’appartements STA et MTA (la pluspard des applications tourne dans un STA)

–          Le thread utilise roGetActivationFactory pour instancié un objet Windows.ApplicationModel.Core.CoreApplication qui crée un  IActivationFactory

(les objets winrt sont manipulés au travers d’interface alors que en .NET/JS on les voit comme des objets)

NB : Les classes système WinRT sont enregistrées dans la registry

–          Les interfaces sont juste des pointeurs vers une VTable (table de pointeur de fonction). La premiere est QueryInterace. On retrouve les méthodes classiques AddRef, Release…

–          A partir de l’interface IActivationFactory, QueryInterface est appelée pour retrouver l’interface attendue.

–          L’interface contient une méthode RunWithBackgroundFactory

–          Le thread appel cette méthode en lui passant un viewProviderFactory (c’est une interface)

–          Elle contient une méthode CreateViewProvider

–          Une fois le viewProvider Créé il va y avoir création d’une instance de WebInstance (dans WWAHost) puis appel des méthodes load et run

 

En résumé : dans l’initialisation un core application est créé et la méthode Run est appellée.

Les vues qui sont créés (à priori des WebInstance) sont créées sur leur propre thread dans un STA.

Voilà c’était pas évident, j’espère avoir à peu près retranscrit correctement le fonctionnement mais comme ça allait super vite il y a certainement quelques coquilles…