Le Post de MCNEXT

Les articles des consultants de MCNEXT

Bienvenue sur le Post de MCNEXT !

conferences_microsoft_usa_700 Les consultants de MCNEXT participent chaque année aux grandes conférences Microsoft aux USA. Retrouvez sur ce blog leurs notes : Frédéric et Sébastien au Pass Business analytics 2015, Guillaume et Benoit à la Build 2015 et Adrien et Stéphane au Microsoft Ignite 2015 (Lien à venir).
A propos de ce blog :
Retrouvez ici les posts des consultants du groupe MCNEXT (déjà plus de 500 !)
Vous voulez en savoir plus sur MCNEXT ou vous souhaitez nous rejoindre ?
Consultez notre site corporate.
Vous pouvez aussi nous suivre sur twitter: @LE_FIL_MCNEXT et regardez nos videos sur notre chaîne YouTube McnextTV !

Héberger un package Nuget sur Team Services et l’alimenter depuis une build

Objectif : 

L’objectif de cet article est de vous présenter comment automatiser depuis Team Services la génération d’un ensemble de classes qui seront ajoutées dans un package NUGET hébergé sur TFS online.

Contexte : 

Une solution VS contient un ensemble de classes communes à plusieurs projets.
Ces classes sont regroupées dans des librairies que l’on veut pouvoir accéder depuis NUGET.

vso_nuget_sc1

Création du container sur VSTS : 

Pour créer le container, vous devez aller dans la section « Packages » du menu « Build & Release ». Si vous ne voyez pas le menu, c’est que vous devez préalablement sélectionner un projet.

vso_nuget_sc2

Si vous n’avez pas le menu package depuis votre interface, vous devez aller dans le MarketPlace et installer Package Management (https://marketplace.visualstudio.com/items?itemName=ms.feed)

Vous pouvez alors ajouter un « feed ». Nous vous conseillons de laisser les options par défaut pour le moment.

Une fois créé, il faut modifier les droits de ce dernier. Pour cela aller dans la section « Permission », et ajouter aux contributeurs les comptes « Project Collection Build Service » et « Project Build Service ». Ces deux comptes sont ceux qu’utilisera le Publisher Nuget lors de la Build.

De même vous pouvez restreindre les accès en lecture à certains groupes si vous le désirez.

vso_nuget_sc3

Le container est maintenant créé, il faut l’alimenter.

Création de la Build : 

Nous allons maintenant créer la Build qui générera le package et le mettra dans le feed. Pour cela aller dans Builds et Cliquer sur « New » et choisir une le template Visual Studio.

Dans les étapes, supprimer les modules « Publish symbols path », « Copy Files » et « Publish Articfact », et ajouter les tâches « Nuget Packager » et « Nuget Publisher ».

On peut commencer le paramétrage de chaque étape.

La première consiste à restaurer les packages Nuget nécessaires à la compilation des projets.
Pour cela on sélectionne le path du fichier solution .sln.

vso_nuget_sc4

On procède de la même manière sur l’étape de compilation.

Comme notre solution comporte des tests unitaires, nous laissons l’étape de tests. Ainsi, s’il y a une régression, la build sera en erreur et le package ne sera pas généré.

Concernant l’étape « Nuget Packager », il est possible de spécifier un fichier .sln ; toutes les dlls de la solution seront alors intégrées dans le package, ou préciser un fichier de configuration.
Pour ne pas ajouter des dlls inutiles (celles du framework, celles des librairies de tests), nous faisons le choix de sélectionner un fichier de configuration .nuspec. Ce fichier ajouté manuellement se trouve à la racine de la solution.
Voici le fichier actuellement utilisé :

<?xml version= »1.0″ encoding= »utf-8″?>
<package xmlns= »http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd »&gt;
<metadata>
<id>CommonLibraries</id>
<version>2.0.1</version>
<authors>MCNEXT</authors>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<developmentDependency>true</developmentDependency>
<summary />
<releaseNotes />
</metadata>
<files>
<file src= »0-Services\bin\Debug\0-Entites.dll » target= »lib » />
<file src= »0-Services\bin\Debug\0-Helpers.dll » target= »lib » />
<file src= »0-Services\bin\Debug\0-Repository.dll » target= »lib » />
<file src= »0-Services\bin\Debug\0-Services.dll » target= »lib » />
</files>
</package>

Les données obligatoires sont l’id, le numéro de version et la liste des fichiers.
Le numéro de version est dans ce fichier une valeur fixe. Elle sera écrasée par la build à chaque incrément.

Voici le détail de la configuration :

vso_nuget_sc5

Remarquons que le package généré se trouvera dans le répertoire $(Build.StagingDirectory) et que nous automatisons le versionning en utilisant l’horodatage.

Enfin la dernière étape consiste à publier le package Nuget généré vers le container créé précédemment.
Nous précisons la localisation du package nuget à déployer, tout en supprimant les packages importés lors de la compilation ; le type de Feed, et l’url de ce dernier qui nous a été fournie lors de sa création.vso_nuget_sc6

 

La build est prête, vous pouvez la lancer pour générer votre premier package.

Maintenant nous allons voir comment l’utiliser dans vos solutions.

Importer le package Nuget dans son projet

La première étape est d’ajouter le container à Visual Studio.
Pour cela aller dans Visual Studio, Outils -> Options, ajouter la source de package avec l’url du feed.

Vous pouvez alors ajouter le package Nuget à votre solution/projet en utilisant le package manager de Visual Studio.

vso_nuget_sc8

Il est possible que pour l’installation ou les mises à jour vous ayez besoin de cocher « Include prerelease ».

Importer le package Nuget lors d’une build

Si votre projet consommateur du package Nuget généré est intégré à une build, il faut préciser à l’agent de Build comment récupérer le package pour compiler.

Pour cela, lors de l’étape de restauration du package Nuget, il ne faut pas préciser le path du fichier Solution (.sln) mais plutôt utiliser un fichier de configuration.

Dans chaque solution, nous avons normalement un fichier NuGet.Config dont nous modifions le contenu comme tel :

<?xml version= »1.0″ encoding= »utf-8″?>
<configuration>
<solution>
<add key= »disableSourceControlIntegration » value= »true » />
</solution>
<activePackageSource>
 <add key= »All » value= »(Aggregate source) » />
</activePackageSource>
<packageSources>
<add key= »nuget.org » value= »https://www.nuget.org/api/v2/ &raquo; />
<add key= »CommonLibraries_DEV » value= »https://monurl.pkgs.visualstudio.com/_packaging/CommonLibraries_DEV/nuget/v3/index.json »/&gt;
</packageSources>
</configuration>

Les informations à ajouter sont le paramètre activePackageSource où nous spécifions que nous voulons importer tous les packages.
Et bien sûr, le package à importer.

Dans la configuration d’une build d’un projet, le path est à préciser dans le champs « Path to Nuget.config »

vso_nuget_sc9

 

La build est paramétrée pour importer correctement le package Nuget créé en interne.

 

Nous venons de voir comment configurer un  package Nuget dans VSTS. Cette génération peut très bien être déclenchée dans le cadre d’une intégration continue.

Une étude plus approfondie peut être faite sur la génération du numéro de version pour éviter de rechercher les nouvelles versions du package en cochant ‘pre-release’.

Why and how we started contributing to Patterns & Practices

Our journey with Patterns & Practices

Our journey with Patterns & Practices started when we first saw the project on GitHub, maybe two years ago. We already had our own internal framework so we just checked what this new tool could do for us. It clearly didn’t cover all our use cases, and we would still have to use our own framework.

Then I came to Ignite in 2015, and I saw Vesa Juvonen presenting the provisioning framework. It was like “Damn, it has grown a lot!”. We started using it as nugget package. It was still not covering all our use cases, but we were migrating our code slowly. As a lot of people were using this project, we found PnP functions more tested than ours, and it was great. We still had our framework tho, but it was disappearing.

But we still had issues:
        We couldn’t debug when we had a problem
        We had to wait for fixes, so we copied PnP functions in our framework to fix them for ourselves
        We had to go to GitHub and browse files to understand fully all we could do with this framework

Contributing

And then, we decided to fork the project (we are using PnP-Sites-Core as a fork, as this is the project we use the most). When you know git (and I really recommend reading at least the first three chapters of the git documentation if you are new to it), it is really fast to set up your environment for development.

Our contribution workflow is:

contribution-patterns-practices

1.      We locally clone our fork
2.      When we want to do some changes, we create a branch for this change that we merge to master when it’s ready
3.      We have a dev branch, created from the tracked PnP-Sites-Core dev branch
4.      When we have something interesting to propose we create a branch, get the commits from our master branch and create the pull request

We then just have to regularly get updates from PnP repositories, and reference our fork as a submodule in other projects.

This new approach has some advantages:
        Our whole team has a better understanding of how the project works
        We can debug
        We don’t have to wait for official fixes
        We can add our own code directly into the framework
        It’s exciting to take part of a bigger community 

5 pull requests merged so far, and a 6th waiting🙂

 

EF6 : Tips&Tricks

EF Core va bientôt prendre la relève mais je pense que EF6 va continué son chemin pendant encore un bon bout de temps avant de disparaître ! C’est pourquoi je me suis dit que j’allais partager avec vous toutes les petites astuces que j’ai découvert ces dernières années.

I. Performances

1) READ_COMMITTED_SNAPSHOT

C’est un paramètre SQL Server au niveau de la base de donnée qui est mis de base en code first, et qui permet « potentiellement » une meilleur scalabilité et moins de deadlocks.

En gros, ça crée un snapshot de la base en read-only sur lequel les SELECT seront executé. Quand un changement s’effectue (par ex : un UPDATE) il s’effectue sur la base (et non sur le snapshot) et un nouveau snapshot de la base est créé.

Ce paramètre est particulièrement adapté lorsque la majorité des requêtes effectuées sont des SELECT.

Commande :

ALTER DATABASE <dbname> SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE <dbname> SET READ_COMMITTED_SNAPSHOT ON;
ALTER DATABASE <dbname> SET MULTI_USER;

2) Warm-up

Lors de la 1ère requête à un Model, EF fait beaucoup de choses avant de pouvoir l’exécuter, cela peut facilement prendre 5-6sec !

Afin d’éviter cela vous pouvez améliorer les choses à plusieurs niveaux, mais personnellement j’ai choisi de contourner le problème en maintenant à chaud mon site sous IIS. Voir cet article de blog pour plus d’infos.

Vous pouvez aussi décider d’utiliser NGEN qui permet d’éviter que l’assembly d’EF (qui est grosse, environ 5Mo) soit JIT à chaque lancement. On peut gagner environ 1-3secondes.

Vous pouvez aussi consulter cet article MSDN pour en savoir plus ce qui se passe et les différentes pistes d’amélioration possibles.

3) Les méthodes async

Sur un site web ou une Web Api le nombre de thread est limité et l’utilisation des méthodes Async de EF permet de libérer le thread courant afin qu’il commence le traitement d’une requête le temps que la base de donnée retourne le résultat.

Plus d’infos sur cet article de blog ou cet article msdn.

4) NoTracking

Lorsque vous faites une requête avec EF, l’état de l’objet est ensuite tracké par le contexte. Régulièrement on n’a pas besoin de ce tracking et cela entraine juste une hausse des consommations CPU/RAM et une perte de performance, surtout dans le cadre de recherche où le nombre d’items retournés est élevé !

Pour éviter de tracker, rien de plus simple, il suffit de rajouter AsNoTracking() à la fin de la query !

Exemple :

var blogs2 = context.Blogs
 .Where(b => b.Name.Contains(".NET"))
 .AsNoTracking()
 .ToList();

5) NCache

NCache est passé OpenSource et peut servir de cache de 2nd niveau pour EF.

6) Break queries

Afin d’améliorer les performances il est souvent préférable de découper une grosse requête en plusieurs petites afin de limiter le nombre d’include.

7) Optimiser les Update via des jointures conditionnelles

Le cas standard d’un update avec EF est le suivant :

L’utilisateur modifie quelques champs -> le client envoie au serveur l’entité entière -> on récupère le graph complet de l’entité côté serveur -> on mappe les champs -> on sauvegarde

Une optimisation courante est donc d’effectuer uniquement les jointures dont on a besoin pour mettre à jour l’entité en base.

La détection du changement peut être faite via le calcul des hashs des entités enfants côté serveur au moment du Get. On recalculera ces mêmes hashs au moment de la sauvegarde et on comparera les hash entre le Get et l’Update pour voir si l’entité enfant doit être mise à jour, et donc si la jointure doit être faite.  Les hashs seront stockés dans une variable au niveau de chaque entité enfants. Pour économiser des cycles CPU serveurs ou de la bande passante ce calcul de hash peut être déporté sur le client.

Exemple

 IQueryable<CLIENT> query = _database.CLIENT; 
 if (clsPersonne.hashIdentiteContactPhysiqueAvant != clsPersonne.hashIdentiteContactPhysiqueApres) 
 query = query.Include(x => x.IDENTITE_CONTACT_PHYSIQUE); 
 ...
 ...
 var client = query.SingleOrDefault(x => x.Id = clsPersonne.Id);

8) Entity Framework Extended Library

Librairie pour EF permettant d’ajouter des fonctionnalités à EF comme les Batch Update/Delete (de base dans EF, on ne peut mettre à jour qu’une ligne par requête).

Permet aussi de gérer un cache simpliste.

9) Au cas où…

N’oublier pas de vérifier vos index et que vos types de données correspondent !

 

2. Les requêtes

1) Mémo pour gérer les graphs d’entités

 

2) Find au lieu de SingleOrDefault

La méthode Find de DbSet permet d’aller récupérer une entité du contexte via sa Primary Key, si l’élément n’est pas trouvé dans le contexte, l’élément est récupéré depuis la base.

Alors qu’avec SingleOrDefault la requête sera toujours exécutée.

3) Logger / Intercepter les requêtes SQL

Une nouveauté peu connue de EF 6.1 est de pouvoir logger les requêtes SQL très facilement, il suffit d’ajouter dans le .config :

<interceptors>
 <interceptor type="System.Data.Entity.Infrastructure.Interception.DatabaseLogger, EntityFramework">
 <parameters>
 <parameter value="C:\Temp\LogOutput.txt"/>
 <parameter value="false" type="System.Boolean"/>
 </parameters>
 </interceptor>
 </interceptors>
  • Booléen à False : Le fichier est réécrit à chaque fois que l’application redémarre
  • Booléen à True: Le texte est ajouté à la fin du fichier

4) Func<> vs Expression<Func<>>

Si on souhaite réaliser un filtre, par exemple:

Expression<Func<YourEntity, bool>> FilterByNameLength(int length)

{

return x => x.Name.Length > length;

}

On l’utilise de la manière suivante :

context.Table.Where(FilterByNameLength(500));

Si vous passer une Func<> à une query EF (pour appliquer un filtre par exemple), la méthode ne sera pas traduite en SQL et sera appliquée a posteriori ce qui est rarement ce que l’on souhaite.

Alors que si on utile une Expression<Func<>> la méthode sera bien traduite en SQL.

5) eSQL

Entity SQL (eSQL) est un language indépendant du stockage permettant de récupérer des données sous formes d’objets ou de forme tabulaire. Cela peut être très pratique pour créer des requêtes dynamiques.

Exemple :

using (AdventureWorksEntities context =
    new AdventureWorksEntities())
{
    string esqlQuery = @"SELECT VALUE Contact
        FROM AdventureWorksEntities.Contacts as Contact where Contact.LastName = @ln";

    // The following query returns a collection of Contact objects.
    ObjectQuery<Contact> query = new ObjectQuery<Contact>(esqlQuery, context, MergeOption.NoTracking);
    query.Parameters.Add(new ObjectParameter("ln", "Zhou"));

    // Iterate through the collection of Contact items.
    foreach (Contact result in query)
        Console.WriteLine("Contact First Name: {0}; Last Name: {1}",
                result.FirstName, result.LastName);
}

6) UnitOfWork

C’est un design pattern qui permet d’abstraire toute la couche de persistence tout en évitant de réinstancier le DBContext à chaque opération (ce qui permet aussi de faire des transactions très simplement). Voir cet article msdn pour plus d’informations.

7) DbFunctions

Cette méthode possède des fonctions utilitaires afin d’effectuer des opérations sur les dates au sein des requêtes EF. Voir la doc MSDN.

8) Jointures externes

Pour cela il faut utiliser DefaultIfEmpty, on l’utilise de la manière suivante :

var q = from c in categories

join p in products on c equals p.Category into ps

from p in ps.DefaultIfEmpty()

select new { Category = c, ProductName = p == null ? "(No products)" : p.ProductName };

III. Divers

1) EF Power Tools

C’est une extension Visual Studio qui permet notamment de :

  • Reverse Engineer Code First : Génère le DBContext, les POCO et le mapping Code First à partir d’une base de données existante (option de base dans VS 2015, via l’ajout d’un modèle ADO.Net)
  • Customize Reverse Engineer Templates : Ajoute le template T4 à votre projet afin de pouvoir customiser la génération de code
  • View Entity Data Model (Read-only) : Affiche une vue du modèle Code First dans le EF designer?
  • View Entity Data Model XML : Affiche l’EDMX XML représentant le Code First.
  • Generate Views : Génère des vues précompilées afin d’améliorer le temps de démarrage de l’application

Plus d’infos ici : https://msdn.microsoft.com/en-us/data/jj593170.aspx

2) Pluralization Service

Vous avez déjà dû le remarquer mais EF possède un algorithme pour mettre aux pluriels les variables, il supporte seulement l’anglais mais vous pouvez faire votre service custom et le pluger à Entity Framework.

Voir cet article pour plus d’infos

 

Voilà, j’espère que vous avez appris quelques petits trucs qui vous faciliteront la vie😉

Tricks : can’t see my LOB app in the Windows Business Store !

If like us you’re desperately trying to publish a new LOB app in your Microsoft Business Store, here is 2 tricks to solve the issue…

Context

Your Windows 10 LOB app is ready to be deployed to your organisation, so you submit it to the store. In the « Pricing and availability » > « Distribution and visibility » section of the submission, you chose « LOB distribution » and checked the store corresponding to your organisation.

Publish LOB app

The certification process is OK, the publication is OK, but the new app doesn’t appear in the Business Store…😦

Empty Business Store

Trick 1

The first trick is you can check if your app is in the store using the URL https://businessstore.microsoft.com/en-us/store/apps/anything/my_app_storeid (to get the store ID of your app, you open the dashboard of your app and go to App management > App Identity).

Business Store LOB app detail

Trick 2

You see your app thanks to the trick 1, but still not in Manage > New LOB Apps page in the Business Store… So the second trick is to check the language you used to describe your in the submission of you  app to the store. In our case, it was in French only. If I switch from en-us to fr-fr in the URL https://businessstore.microsoft.com/fr-fr/lob/AppDetails, I can now see my app !

Add LOB app to the inventory

And I can add it to the inventory of my private store !

 

Création d’un cluster SQL SERVER 2016 dans Azure (IAAS)

Objectif :

L’objectif de ce blog est de vous présenter toutes étapes permettant de créer un système de haute disponibilité  SQL SERVER dans Azure

Voici un peu le détail de l’architecture :

1

Dans ce blog nous allons aborder les sujets suivants :

  • Création du réseau virtuel permettant aux machines de communiquer
  • Création des VM nécessaires à notre architecture
  • Installation des Contrôleurs de domaines depuis Azure
  • Préparation du cluster
  • Installation de SQL Server 2016 en mode cluster

Pré requis :

  • SQL SERVER 2016
  • Un compte Azure
  • 1 réseau virtuel
  • 4 machines Virtuelle :
  • 2 Contrôleurs de domaine (DC1 / DC 2) (Windows Server 2012 R2)
  • 2 machines SQL SERVER 2016 (Windows Server 2012 R2)
  • De l’huile de coude et un peu de bonnes volontés🙂

Partie 1 : Création d’un réseau virtuel 

Afin que nos machines puissent communiquer nous allons créer un réseau virtuel :

2

3

Le reseau est créé :  4

Partie 2 :Création des 4 machines virtuelles nécessaires à notre configuration :

Dans le portail Azure il faut vous rendre dans l’onglet :

Machine Virtuelles :

5

Nous recherchons Windows Server 2012 R2 DATACENTER

6

Une fois la sélection faite nous allons choisir le type de machine pouvant héberger notre « labs » de test :

7

Dans notre cas j’ai choisis 2 machine A0 de base pour les machines Active Directory et 2 machines A1 de base pour les machines SQL Server.

Il est évident que pour des configurations de production ces machines seraient trop juste et risquerai d’être sous dimensionnée par rapport à vos besoins.

Suivant vos besoins vous être libre de choisir les machines qui se rapproche le plus de votre usage.

Voici le détail de création des machines, vous devez répliquer cette opération autant de fois que votre architecture le nécessite.

8

9

 

Partie 3 Installation du contrôleur de domaine :

Un fois la machine DC1 installée connectez vous en remote et installez l’active Directory :

Rendez vous dans Add Roles and Features sur le Serveur :

17.jpg

Choisissez le service Active Directory

14

Une fois installé rendez vous dans l’onglet active directory :

18

Une fois réalisé il faut promouvoir le controleur de domaine :

19

Votre Active Directory est créée

Il faut rajouter le DNS de la machine primaire a toutes les machines du réseau :

Rendez vous sur le portail azure et dans les paramètre de votre machine modifier le serveur DNS Mettez l’adresse du DNS principal comme celui de votre controleur de domaine que vous venez de créer :

22

Ajouter le DC2 en nouveau contrôleur de domaine sur le domaine :

24

Si vous avez besoin d’aide pour l’installation d’un contrôleur de domaine vous pouvez suivre les étapes suivantes :

http://www.windows8facile.fr/windows-server-2012-installer-active-directory-dns-dhcp/

Une fois votre active directory installé vous pouvez ajouter vos 2 machines SQL au Domaine.

N’oubliez pas d’ajouter le DNS secondaire a vos machine le DNS secondaire correspondant a l’adresse IP de la machine DC2.

23

 

Une fois les machines SQL relié on va préparer l’installation du cluster :

On va ajouter 2 disques qui nous permettrons de faire la réplication :

Dans le portail Azure réaliser l’étape suivante :

25

Le disque va s’ajouter sur la machine il faut le formater et le monter pour qu’il soit disponible :

Aller dans le computer management :

26

Ensuite Formater le volume et attribuez lui la lettre F comme lettre de montage :

 

Sur la machine nous allons installer le cluster

27

Sur la machine nous allons installer le cluster ( On retourne dans le menu Add Roles and Features )

28

En suite connecter vous au portail de configuration et effectuez les opérations suivantes :

29

Cliquer sur Validate Configuration et effectuer les opérations suivantes :

3031323334

Il faut en suite modifier les propriétés de l’adresse IP du Cluster :

35.jpg

Rendez-vous sur le DC1 ou DC2 et ajouter un répertoire qui va nous permettre de créer le Quorum du cluster :

C:\Quorum :

Ajouter les droits en lecture / Ecriture au cluster sur ce répertoire (le cluster étant un ordinateur)

1

 

2

Retourner sur la machine SQL1 et réaliser les actions suivantes :

3

 

476

Telechager DataKeeper qui est un outil qui va nous permettre de simuler le SAN d’hébergement de notre cluster et le miroir de stockage sur azure.

Datakeeper est disponible ici et peut être demandé en version de démonstration pour 14 jours.

Pour plus d’information : http://us.sios.com/products/datakeeper-cluster/

Installer Datakeeper et ajouter y votre licence :

8

Ouvrir l’outil Datakeeper et réaliser les actions suivantes :

Creer un job :

Connectez vous  aux deux serveurs SQL ( SQL1 et SQL2 )

910

Nommer le job comme vous le souhaitez.

Attention pour fonctionner DataKeeper necessite qu’un second disque soit monter pour réaliser le miroir ( action que nous avons réaliser précédement)

Içi nous allons « mirrorer » les disques F que nous avons monter précédements, ils permetteront d’heberger notre cluster :

1112

Nous allons creer un mirroir synchrone pour notre cas :

13

Une fois l’action réalisé DataKeeper nous informe que le volume est éligible au cluster cliquez sur oui :

 

14

Dans DataKeeper verifier que la synchronisation fonctionne bien :

 

15

Partie 4 :Installation de SQL Server 2016 :

Sur la machine SQL 1 :

16171819

Dans notre cas nous allons faire demarrer le service avec notre compte administrateur mais l’idéal est de creer un compte de service spécifique pour le demarrage des services

2021

En suite lancer l’installation suivante :

2223242526

On spécifie une IP pour le Cluster SQL Server

27

Ne pas oublier d’ajouter un administrateur

28

 

Rendez-vous sur la machine SQL2 :

313233343536

Votre cluster est prêt :

N’oubliez pas d’activer les ports distants pour accéder depuis l’extérieur a SQL Server  :

Et d’installer le management studio :

40

pour l’installer cliquer sur le liens suivant qui va vous envoyer sur une page web pour telecharger l’outil et l’installer :

39

Merci a Datakeeper pour leur aide dans l’élaboration de ce tutoriel :

Si vous avez besoins voici des liens utiles :

Creating a SQL Server 2014 AlwaysOn Failover Cluster (FCI) Instance in Windows Azure IaaS #Azure #Cloud

https://azure.microsoft.com/fr-fr/documentation/articles/active-directory-new-forest-virtual-machine/

https://channel9.msdn.com/Series/Windows-Azure-IT-Pro-IaaS/05

https://azure.microsoft.com/fr-fr/documentation/articles/active-directory-install-replica-active-directory-domain-controller/

Windows Server Failover Cluster on Azure IAAS VM – Part 1 (Storage)

https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-classic-portal-sql-alwayson-availability-groups/

Bon courage.

Julien PIERRE                                                                                                                                       Consultant MSBI

 

 

 

 

 

#UWPXAML – Compiled Binding – What’s new in the Anniversary Update?

Coming this summer, Windows 10 Anniversary Update will be more or less a Windows 10 v2.0.
With it comes a lot of new things for the windows app development, and a lot of new features and fixes for Compiled Binding.

Today we’ll see what those new features are and how to use them.

If you want to try them out yourself, you’ll need a Windows Insider build of Windows 10 with its Windows SDK and create a UWP project targeting a min version at least equals to Build 14383. Do not install it on your main work station, it will break any non-Anniversary Update apps.

For this post, I’ll use Windows 10 Build 14383 (available on Fast Ring) with Visual Studio 2015 Update 3.
The Windows SDK for Build 14383 can be found here: https://insider.windows.com/

In case you missed it, I wrote a few posts about compiled binding in the past.
Feel free to read them (again).

 

Function binding

Previously, it was possible to directly bind events to methods which followed specific rules regarding their parameters, but we were unable to bind the result of a method to a property without a converter which was calling the method for us.

Now, it’s possible to bind methods directly to properties without the need for a converter!
You can provide whatever method you like as long as it has a public accessor and you provide the parameters.

MainPage.xaml.cs

public sealed partial class MainPage : Page
{
    public MainPage()
    {
        this.InitializeComponent();
    }

    public string GetHelloWorld()
    {
        return "Hello World";
    }

    public Person Roberts = new Person()
    {
        Firstname = "Dread Pirate",
        Lastname = "Roberts"
    };
}

Person.cs

public class Person
{
    public string Firstname { get; set; }
    public string Lastname { get; set; }

    public string GetFullname()
    {
        return $"{Firstname} {Lastname}";
    }
}

MainPage.xaml

<TextBlock Text="{x:Bind GetHelloWorld()}" />
<TextBlock Text="{x:Bind Roberts.GetFullname()}" />

The method can have parameters.
You can provide them by setting constants in the XAML or by using data from your ViewModel.

MainPage.xaml.cs

public sealed partial class MainPage : Page
{
    public MainPage()
    {
        this.InitializeComponent();
    }

    public DateTime Today = DateTime.Now;

    public Person Someone = new Person()
    {
        Firstname = "Some",
        Lastname = "One"
    };        

    public string GetPersonFullname(Person person)
    {
        return person.GetFullname();
    }
}

MainPage.xaml

<TextBlock Text="{x:Bind Today.ToString('d', {x:Null})}" />
<TextBlock Text="{x:Bind GetPersonFullname(Someone)}" />

Does the binding is automatically updated when the data is updated?
Well, it is said to work if you set the Mode of the compiled binding to OneWay/TwoWay but I wasn’t able to compile it under VS2015. A few not really understandable compile errors appeared when I used TwoWay binding.

Along that, you may notice some errors appearing in the Error list when using parameters inside your binded functions stating « A value does not fall within the expected range ». It’s a bug of VS2015, but it compiles and runs fine anyway.

I hope those annoying errors will be fixed in the release version.
 

Dictionary indexers

As part of supporting most use cases without the need for a converter, x:Bind now supports access to a specific key in a dictionary.

MainPage.xaml.cs

public sealed partial class MainPage : Page
{
    public MainPage()
    {
        this.InitializeComponent();
    }

    public Dictionary<string, string> Dictionary = new Dictionary<string, string>()
    {
        { "A", "Alpha" },
        { "B", "Beta" },
        { "C", "Charlie" },
    };
}

MainPage.xaml

<TextBlock Text="{x:Bind Dictionary['A']}" />
<TextBlock Text="{x:Bind Dictionary['B']}" />
<TextBlock Text="{x:Bind Dictionary['C']}" />

It works great but there is a big shortcoming: You can only use constant strings directly set in the XAML.
Using anything else than a string, like an integer, will result in a compile error.
Even string data from your ViewModel won’t work.
 

Explicit value cast

Contrary to classic Databinding which uses duck typing to check if the binding is valid, compiled binding checks at compile time that the given data matches the property to which it is binded to.
In other words, if the value you’re trying to bind has no implicit cast to the type of the property, you can’t bind it using x:Bind without a converter.
Even if the value’s type declares an explicit cast…

As of the Anniversary Update, you will be able to declare an explicit cast inside a compiled binding, C#-style.

MainPage.xaml.cs

public sealed partial class MainPage : Page
{
    public MainPage()
    {
        this.InitializeComponent();
    }

    public bool? IsThreeStateNull = null;
}

MainPage.xaml

<CheckBox Content="IsThreeState = False" IsThreeState="{x:Bind (x:Boolean)IsThreeStateNull}" />

When casting explicitly, you’ll need to refer to the class type by its XAML namespace.
In this case, Boolean is part of the « x: » namespace declaration.
 

Implicit Visibility conversion

Who don’t know the legendary BooleanToVisibilityConverter?
Everyone, since the first time WPF came around, implemented it over and over in every projects.

x:Bind no longer requires that, it now converts booleans to Visibility by itself! Hurray!
You just need to bind a boolean to a property like Visibility.

MainPage.xaml.cs

public sealed partial class MainPage : Page
{
    public MainPage()
    {
        this.InitializeComponent();
    }

    public bool IsVisibleFalse = false;
    public bool IsVisibleTrue = true;
}

MainPage.xaml

<TextBlock Text="I'm not visible!" Visibility="{x:Bind IsVisibleFalse}" />
<TextBlock Text="I'm visible!" Visibility="{x:Bind IsVisibleTrue}" />

 

Conclusion

You can find a sample project on GitHub regrouping all the examples we saw in this post: http://github.com/TimLariviere/CompiledBinding-AnniversarySample

Écriture/lecture/modification de fichiers dans un projet Universel app/UWP et cordova

Dans nos applications, nous avons pris le parti d’écrire nos fichiers en JSON. Nous avons donc conçu une abstraction (en WinJS, avec un système de promises) qui nous permet d’utiliser des méthodes claires et simples sur toutes les plateformes (WinRT/UWP ou Cordova (iOS/Android) )

Ce module « DataContainer » est disponible dans notre libraire WinJSContrib (Github)

Dans WinJSContrib.DataContainer, nous avons 4 fichiers qui exposent les mêmes méthodes avec des implémentations différentes :

  • read : lecture d’un élément
  • save : enregistrement d’un élément
  • remove : suppression d’un élément
  • list : liste des fichiers d’un container
  • child : création/accès container enfant

Dans une application WinRT/UWP nous allons naturellement utiliser la couche WinRT/UWP pour écrire/lire les fichiers. Pour cela il suffit d’inclure le fichier « winjscontrib.datacontainer.winrt.file.js »

Dans une application cordova IOS ou Android, nous avons plusieurs choix :

  • Utiliser une base de données : winjscontrib.datacontainer.cordova.database.js
  • Utiliser le système de fichiers avec le plugin file : « winjscontrib.datacontainer.cordova.file.js »
  • Utiliser le localStorage : « winjscontrib.datacontainer.localstorage.js » (utilisable en WinRT aussi)

Ensuite, il faut instancier un container parent et l’utiliser partout dans l’application.

Dans le JS des applications Windows 8/Phone il suffit d’instancier le container (dossier) parent :

MyApp.Data.container = new WinJSContrib.DataContainer.WinRTFilesContainer(undefined, { logger: WinJSContrib.Logger });

Et changer WinRTFilesContainer par notre choix (CordovaDatabaseContainer par exemple) pour l’application cordova en faisant attention de ne l’appeler qu’après l’enclenchement de l’évènement deviceready.

Et c’est tout, la magie s’opère à l’intérieur de notre librairie🙂

Quelques exemples d’utilisation :

  • Pour lire un fichier :
  • Data.container.read(&quot;objKey&quot;).then(function (data) { }, function (error) { });
    
  • Supprimer un fichier :
  • Data.container.remove(&quot;objKey&quot;).then(function () { }, function (error) { });
    
  • Enregistrer un fichier :
  • Data.container.save(&quot;objKey&quot;,obj).then(function () { }, function (error) { });
    
  • Accès à un container enfant (sous dossier) avec la lecture d’un fichier fichier :
  • Data.container.child(folderid).read(&quot;subObjKey&quot;).then( function (subObjInFolderID) { }, function (error) { }));
    
  • Liste des fichiers dans un container :
  • Data.container.list().then(function (res) {}, function (error) { });
    

Workaround to use and debug TypeScript with UWP apps and Visual Studio 2015 update 2/3

Since the Update 2 of Visual Studio, the TypeScript debugging in UWP apps is broken.

After a lot of discussions on the TypeScript repo, Mine Yalcinalp Starks give me a workearound that works just perfectly🙂

And here the solution (I assume you’re running in an English locale here, otherwise I don’t think the workaround is applicable):

Close VS.
In an administrator command prompt:

cd %ProgramFiles(x86)%\msbuild\microsoft\visualstudio\v14.0\typescript
mkdir en
copy *.xaml en
copy TypeScript.Tasks.dll en\TypeScript.Tasks.resources.dll

The behavior that breaks the TypeScript integration in UWP (In reality, typescript is not officially supported in UWP apps, it will be in VS15 « next ») is potentially due to a TypeScript installation bug.

Tricks : Gérer son numéro de version au niveau de la solution

Si comme moi, vous avez toujours rêvé de pouvoir gérer son numéro de version au niveau de solution et non au niveau de chaque projet cet article est fait pour vous !

Marche à suivre

  1. Click droit sur la solution -> Ajouter un nouvel item -> Classe Visual C#
  2. Nommez le fichier « SharedAssembyInfo.cs »
  3. Reprenez toutes les infos d’un « AssemblyInfo.cs » d’un projet existant et copier-coller le contenu dans « SharedAssembyInfo.cs ». Les fichiers « AssemblyInfos.cs » se trouvent dans la rubrique « Properties » située juste au-dessus de « Références ».
  4. Mettez en commentaire tout le contenu des différents « AssemblyInfo.cs »
  5. Sur chaque projet :
    1. Click droit -> Ajouter élément existant
    2. Sélectionner le « SharedAssembyInfo.cs »
    3. Choisir d’ajouter en tant que lien
    4. Faites glisser le fichier ajouté au projet dans le dossier « Properties »

A savoir

Vous n’êtes pas obligé de partager toutes les informations dans le « SharedAssembyInfo.cs », tout ce qui est spécifique à chaque projet vous pouvez le laisser dans le « AssemblyInfos.cs » du projet.

Pour allez plus loin

Savez-vous que vous pouvez générer un numéro de build sans usine de build depuis Visual Studio? Pour cela il suffit de :

  1. Mettre en commentaire l’attribut « [assembly: AssemblyFileVersion(« 1.0.0.0 »)]» que l’on trouve dans « SharedAssembyInfo.cs » ou « AssemblyInfos.cs ». Seul l’attribut « AssemblyVersion » doit être spécifié.
  2. Mettre l’attribut « AssemblyVersion » sous la forme : « [assembly: AssemblyVersion(« Majeur.Mineur.* »)] »

Après ça, à chaque build, Visual Studio va remplacer l’étoile par un « numéro de build » et un « numéro de révision » :

  • Numéro de build : Le nombre de jour depuis le 1er Janvier 2000.
  • Numéro de révision : Le nombre de secondes depuis minuit divisé par 2.

 

J’espère que cet article vous aura été utile😉

 

Sources

http://weblogs.asp.net/ashishnjain/sharing-assembly-version-across-projects-in-a-solution

http://www.csharpcity.com/2012/visual-studio-automatic-version-numbering/

https://msdn.microsoft.com/en-us/library/k49w9389(v=vs.110).aspx

Xamarin – Using SQLite.NET Async with PCL

With Xamarin, it is now easier than ever to share most of the logic between your apps.
Most today’s apps use a lot of data, so deciding how to store them locally can prove a challenge.
SQLite provides a great way to store and query those easily and does support Xamarin. Hurray!

In this post, we’ll see how to setup SQLite in a portable project (PCL) shared by two Xamarin projects (Android, iOS) and a UWP project in Visual Studio.
It should be more or less the same with Xamarin Studio.

If you’re interested in using SQLite.NET with Xamarin.Forms, see the Xamarin.Forms documentation instead.

Portable class library and NuGet packages

First of all, we’ll need to create a portable class library supporting Android, iOS and Windows.
Conveniently, Visual Studio provides a template which exactly fits our needs.

PCL.PNG

If for any reason you can’t or won’t use this template, you can use the generic « Class Library (Portable) » template instead.
See Xamarin’s Introduction to Portable Class Libraries for more information on it.

Then, we’ll need to add references to SQLite.NET via the NuGet package SQLite.NET.Async-PCL v3.1.1 which comes along with its dependency SQLite.Net.Core-PCL.

Nuget1.PNG

That’s all we need to setup the PCL in order to use SQLite.NET.

Using SQLite.NET

Now for the tricky part.

We can now use SQLite in the PCL and thus write it once and be able to use it on each platform. But in order to do so, we’ll need a connection to the SQLite database (and need to create it if it’s not the case).

As we’re targeting three different platforms, each with its own rules on how to access the storage space, SQLite.NET needs several things in order to work : a path to where SQLite should store the database file and a custom implementation of the wrapper around the native sqlite3.

For that, as we’re using SQLite.NET Async, we need to create a SQLiteAsyncConnection.
It’s fairly simple.

public class SQLiteDatabase
{
    public static SQLiteAsyncConnection GetConnection(string path, ISQLitePlatform sqlitePlatform)
    {
        var connectionFactory = new Func<SQLiteConnectionWithLock>(() => new SQLiteConnectionWithLock(sqlitePlatform, new SQLiteConnectionString(path, storeDateTimeAsTicks: false)));
        return new SQLiteAsyncConnection(connectionFactory);
    }
}

See what we did there?
We have created a connection to the SQLite database but all the platform-specific parts are passed as parameters, allowing us to have a common method in the PCL project.

The path parameter is a file path which SQLite will use to store its db file.
The ISQLitePlatform parameter is described in the SQLite NuGet package and represents an internal implementation of SQLite for a given platform. Don’t worry, it has already been done for us for Android, iOS and UWP.

Of course, you can use dependency injection or any architecture that fits your needs instead. The key point here is to leave the implementation detail to the output projects.

We’ll come back shortly after to these platform-specific parameters.

For now enjoy!

public class MyEntityRepository
{
    private SQLiteAsyncConnection _connection;

    public async Task InitializeAsync(string path, ISQLitePlatform sqlitePlatform)
    {
        _connection = SQLiteDatabase.GetConnection(path, sqlitePlatform);

        // Create MyEntity table if need be
        await _connection.CreateTableAsync<MyEntity>();
    }

    public async Task<MyEntity> CreateAsync(string name)
    {
        var entity = new MyEntity()
        {
            Name = name
        };
        var count = await _connection.InsertAsync(entity);
        return (count == 1) ? entity : null;
    }

    public async Task<IEnumerable<MyEntity>> GetAllAsync()
    {
        var entities = await _connection.Table<MyEntity>().OrderBy(m => m.Name).ToListAsync();
        return entities;
    }
}

 

Android / iOS / UWP projects

Xamarin.Android and Xamarin.iOS will both need the exact same configuration regarding SQLite.NET, but UWP will need one extra small step.

Along with the obvious reference to the PCL project, we’ll need to reference the SQLite.NET-PCL v3.1.1 NuGet package as well.
Warning : it is not the same package as the one we used earlier.

This one automatically includes the previously seen ISQLitePlatform implementation of the targeted platform.
When referenced in an output project, it brings another dependency with it where all the platform-specific implementation is present.

  • SQLite.Net.Platform.XamarinAndroid when referenced in a Xamarin.Android project
  • SQLite.Net.Platform.XamarinIOS in a Xamarin.iOS project
  • SQLite.Net.Platform.WinRT in a UWP project

Last step is to use our MyEntityRepository by giving it all the platform specific parameters.

Android

private string GetDbPath()
{
    string documentsPath = System.Environment.GetFolderPath(System.Environment.SpecialFolder.Personal);
    return Path.Combine(documentsPath, "Todo.db3");
}

protected override async void OnCreate(Bundle bundle)
{
    base.OnCreate(bundle);

    // Set our view from the "main" layout resource
    SetContentView(Resource.Layout.Main);
    var addButton = FindViewById<Button>(Resource.Id.AddButton);
    var todoListView = FindViewById<ListView>(Resource.Id.TodoListView);
    addButton.Click += OnAddButtonClicked;

    _todoRepository = new TodoRepository();

    var path = GetDbPath();

    await _todoRepository.InitializeAsync(path, new SQLitePlatformAndroid());
    var items = await _todoRepository.GetAllAsync();

    todoListView.Adapter = new ArrayAdapter<string>(this, global::Android.Resource.Layout.SimpleListItem1, items.Select(i => i.Text).ToList());
}

private async void OnAddButtonClicked(object sender, EventArgs e)
{
    var todoEditText = FindViewById<EditText>(Resource.Id.TodoEditText);
    var text = todoEditText.Text;
    todoEditText.Text = string.Empty;

    var todoItem = await _todoRepository.CreateAsync(text);
            
    var todoListView = FindViewById<ListView>(Resource.Id.TodoListView);
    var adapter = todoListView.Adapter as ArrayAdapter<string>;
    adapter.Add(todoItem.Text);
}

 

iOS

private string GetDbPath()
{
    string documentsPath = Environment.GetFolderPath(Environment.SpecialFolder.Personal);
    return Path.Combine(documentsPath, "..", "Library", "Todo.db3");
}

public override async void ViewDidLoad()
{
    base.ViewDidLoad();
    AddButton.TouchUpInside += OnAddButtonTouchUpInside;
            
    _todoRepository = new TodoRepository();

    var path = GetDbPath();

    await _todoRepository.InitializeAsync(path, new SQLitePlatformIOS());
    var items = await _todoRepository.GetAllAsync();
            
    TodoTable.Source = new TodoTableDataSource(items, TodoTable);
    TodoTable.ReloadData();
}

private async void OnAddButtonTouchUpInside(object sender, EventArgs e)
{
    var text = TodoTextField.Text;
    TodoTextField.Text = string.Empty;

    var todoItem = await _todoRepository.CreateAsync(text);

    var source = TodoTable.Source as TodoTableDataSource;
    source.Add(todoItem);
}

 

Universal Windows Platform

Remember that one extra small step ? Now is the time to take care of it.

Windows, contrary to Android and iOS, doesn’t have SQLite3 installed by default. So we need to bring sqlite3.dll along in our appx package otherwise we’ll get an exception « Unable to load sqlite3.dll ».
To do so, we’ll need to install the Visual Studio extension for UWP which can be found on the SQLite official website.

Then we just have to add two references in our UWP project.

  • SQLite for Universal Windows Platform (that’s our sqlite3.dll added by the VSIX)
  • Visual C++ 2015 Runtime for Universal Windows Platform (it’s a dependency of the former)

 
Capture.PNG
And that’s all for that extra small step.

Now we can use SQLite like in the Android and iOS projects.

public ObservableCollection<TodoItem> Items { get; set; } = new ObservableCollection<TodoItem>();

private async Task<string> GetDbPathAsync()
{
    var folder = Windows.Storage.ApplicationData.Current.LocalFolder;
    var file = await folder.CreateFileAsync("Todo.db3", CreationCollisionOption.OpenIfExists);
    return file.Path;
}

protected override async void OnNavigatedTo(NavigationEventArgs e)
{
    _todoRepository = new TodoRepository();

    var path = await GetDbPathAsync();

    await _todoRepository.InitializeAsync(path, new SQLite.Net.Platform.WinRT.SQLitePlatformWinRT());

    var items = await _todoRepository.GetAllAsync();
    foreach (var todoItem in items)
    {
        Items.Add(todoItem);
    }
}

private async void OnAddTodoItemButtonClicked(object sender, RoutedEventArgs e)
{
    var text = TodoTextBox.Text;
    TodoTextBox.Text = string.Empty;

    var item = await _todoRepository.CreateAsync(text);
    Items.Add(item);
}

 
And there we are! That’s all for today.
Go make some happy users with great apps using SQLite.NET and Xamarin!
 
I’ve put up a sample project on GitHub, it’s a simple Todo list app working on Android, iOS and UWP : https://github.com/TimLariviere/XamarinSQLite