Ça, c’est la poisse: Your account has no free minutes remaining.

Le scénario est à se pendre, tu montes ton projet en intégration continue et après quelques (dizaines) de commit tu te retrouves dans l’impossibilité de complétera une PR ou juste vérifier que le dernier commit n’a pas introduit de régressions.

Du coup je me propose de présenter ici, comment créer à moindre frais un agent de build sur-vitaminé. Et le fait d’avoir une machine un peu costaud, n’est pas un moindre mal ; qui ne s’est pas arraché les cheveux en attendant que l’agent de build hosté veuille bien se lancer et faire son travail… ?

Plutôt que de créer nous même une vm, installer windows, msbuild et tout le nécessaire a un agent de build, on va plutôt utiliser azure DevTest Lab. L’idée est de tirer parti des template de vm qui sont mises a notre dispo.

Après avoir créé votre première instance DevTest lab, on ajoute une vm basée sur l’image Visual Studio Community 2017 (latest release) on Windows Server 2016 (x64).




On va vous demander un login et un mot de passe pour le compte admin de la future vm.
Je vous conseille de stocker votre mot de passe dans le coffre-fort « my secret » pour une plus grande sécurité. (ce n’est donc pas mon mot de passe que vous voyez 😊)

Bon il nous faut maintenant choisir les caractéristiques de la vm. J’ai opté pour 32 GO de ram et 8 vcpu, une D8S_V3, elle ne sera allumée que quelques minutes le temps de faire le build, donc elle ne nous coutera pas bien cher.

Place aux artefacts, il convient de voir cela comme des scripts additionnels qui installeront d’autres programmes/services sur votre vm. Ça tombe bien, l’artefact VSTS Build agent nous procure le service de build qui convient.




Quelques précisions, le champs VSTS account name doit se conformer au pattern suivant : https://{{vsts_account_name}}.visualstudio.com

Le secret correspond une clé privée que vous pourrez crée en vous rendant à l’adresse https://{{vsts_account_name}}.visualstudio.com/_details/security/tokens

Finalement, l’agent pool doit être un pool pré-existant. A vérifier/créer ici : https://{{vsts_account_name}}.visualstudio.com/_admin/_AgentPool

Petit plus, dans le cas ou vous envisagez de builder des projets front, profitez de cette étape pour ajouter l’artefact NODE JS.

Bon, aller y’a plus qu’a cliquer sur OK, attendre quelques minutes et l’agent devrait apparaitre dans le pool que vous avez choisi.



Quoi qu’il en soit pas de panique, si vous vous êtes trompé sur un paramètre des artefacts, il sera toujours possible de retenter l’installation a postériori ou bien de procéder a l’installation manuellement.

Dernier point, si vos crédits azure ne vous permettent pas de laisser cette vm allumée tout le temps, voici deux petites commandes qui vous permettront d’allumer et d’éteindre la vm a volonté. (a utiliser dans une console azure cli

az lab vm {{command}} --lab-name {{devtestlab}} --name {{vm-name}} 
--resource-group {{resource-group}}

command : start ou stop
devtestlab : le nom de votre instance DevTest lab
vm-name : le nom de votre vm
resource-group : le nom du resource group ou est installé la vm.

Dernièrement, j’ai pas mal fait joujou avec OData.
C’est quand même super plaisant de pouvoir requêter une source de données via une URL et avec une richesse proche de ce que l’on connait avec du SQL.
Une fois n’est pas coutume je ne vais pas parler de .NET mais plutôt partager avec vous un bout de javascript qui met en évidence la facilité avec laquelle vous pourrez brancher des tables ngtable avec votre backend odata.

Trêve de bavardage, on passe au code :



Pour cette illustration, j'ai utilisé le web service services.odata.org qui expose la base Northwind (sample Microsoft) que l'on a tous croisés un jour.

Juste un mot sur le code, évidemment c'est le service odataTableService qui fait la glue entre OData et ngTable; c'est lui qui permet de réaliser les filtrages et les sorts. Une fois que ce service est disponible dans votre app, regardez avec quelle simplicité, votre controller peut créer une table :

$scope.tableParams = odataTableService.createTableParams({
      endPoint: 'http://services.odata.org/V3/Northwind/Northwind.svc/Products'
    });

Je me demande vraiment pourquoi OData n'a pas plus que ça le vent en poupe.

Que ce soit manuellement ou de manière automatique, lorsque l'on parle de déploiement il va nous falloir définir un package de déploiement.

Dans l'univers Octopus, les packages de déploiement sont des fichiers avec une extension .nupkg. Voyons comment en créer un pour un projet de Base de données.

Ajouter une dépendance vers Octopack

Octopack est l’utilitaire que nous allons utiliser pour générer ce package de déploiement. Démystifions le terme, octopack produit un fichier qui n’est autre qu’un zip, contenant les fichiers à déployer ainsi qu’un ensemble de métadonnées et potentiellement des scripts powershell.
Bref, rien de bien extraordinaire.

Pour l’installer dans notre projet de base de données, nous allons utiliser Nuget, qui est un gestionnaire de dépendances très performant et bien connu des développeurs. Cependant il n’est pas facilement accessible lorsqu’on travailler sur un projet SQL/SSIS/SSRS/SSAS.

Pour tromper Visual Studio nous allons commencer par ajouter un projet C# de type console pour faire simple



Ajoutons sur ce projet C# une dépendance vers Octopack.



Dans la nouvelle fenêtre on cherche le package Octopack, et on l’installe.



Après avoir acquitté la fenêtre de preview d’install, la fenêtre «Output» de visual Studio devrait vous confirmer que l’installation s’est bien passée.



Il aurait été formidable de pouvoir l’installer directement dans notre projet de base, mais nous allons devoir transpirer un peu plus pour arriver à nos fins.
Ready ?? Ouvrons le fichier csproj de l’application console et copions la portion de msbuild qui correspond à Octopack



Puis, copions la discrètement dans notre fichier sqlproj, de la même manière à la fin de celui-ci.
Un petit rebuild pour vérifier que tout fonctionne toujours bien… et TADAM y’a toujours pas de package de déploiement généré.

Créer le package

Bon si vous avez été un peu curieux, vous aurez remarqué que la portion de msbuild que l’on a copiée a pour but d’importer un autre fichier msbuild (qui se trouve dans le répertoire packages\OctoPack.3.4.1\tools\OctoPack.targets)

En baragouinant un peu le msbuild, on comprend assez vite que la variable RunOctoPack est initialisée à false et c’est elle qui déclenche ou non la génération du package.

Alors évidemment, une solution possible est de modifier cette variable à true. Néanmoins cela induit qu’un package de déploiement sera créé a chaque build du projet. Ce n’est vraisemblablement pas ce que vous souhaitez.

Je vous propose plutôt d’ouvrir une console DOS et une fois dans le répertoire du projet, tapez la commande suivante :

msbuild ContinuousBI.Sql.sqlproj /t:Build /p:RunOctoPack=true

Si tout s’est bien passé vous devriez avoir une sortie similaire a celle-ci :



Cette fois ci, si vous jetez un œil dans le sous-dossier obj/octopacked de votre projet vous y découvrirez un fichier .nupkg qui est le package de déploiement

A quoi ressemble mon package ?

Pour aller un peu plus loin nous pouvons jeter un œil à ce qui a été produit pour nous par Octopack.
Je vous propose d’utiliser nuget package explorer
Ouvrez le et glissez déposez le fichier .nupkg, vous devriez obtenir un résultat semblable à celui-ci.



C’est confirmé, le dacpac issu de la compilation à bien été reconnu ; il est embarqué dans package de déploiement.

Nous verrons dans le prochain post comment le déployer avec Octopus.

Dernièrement j'ai ressorti ma BeableBone Black histoire de faire une peu de veille techno. J'vous raconterai un de ces quatre en quoi monter une boite peut vite cramer tout votre temps libre, mais c'est pour la bonne cause.



Bref pour en revenir à la Beagle, je ressors mon câble série que j'utilise pour me connecter à la console. Je fais les branchements et go sur le site de Prolific pour récupérer le dernier driver pour Windows 10.

Tiens! bizarre, même après un reboot je n'ai toujours rien qui s'affiche dans mon terminal.
En creusant, je m'aperçois que le driver du câble n'est pas reconnu.



S'en suit plusieurs tentatives de réinstallation et de reboot infructueuses.

Je cherche un peu sur Internet, pas mal de personnes ont des soucis avec des versions contrefaites acheté sur des sites asiatiques. Le mien vient de chez Adafruit, et il fonctionnait parfaitement il y a quelques mois, sur Windows 8.

Ho... tiens réessayons sur cet ancien PC. Ca fonctionne parfaitement!
Énorme je récupère l'installer du driver qui se trouve sur ce dernier;
Je repasse sur mon PC équipé de Windows 10, désinstalle le driver en place, reboot, installe l'ancien driver (fonctionnant sur Windows 8) et surprise, ca fonctionne.

Si ça c'est pas de l'obsolescence programmée! Honteux!
Rien que pour ça, je vous recommande plutôt d'investir dans un câble concurrent comme ce FTDI. J'en possède un également et fonctionne tout aussi bien.

Du coup, je vous dépose le driver fonctionnel, ici. J'espères que cela pourra aider quelqu'un.

Tiens, en prime je poste ici le schéma de branchement du câble Prolific avec la beagle.

• Le fil noir va sur le pin 1 (GND)
• le fil vert sur le pin 4 (RECEIVE)
• le fil blanc sur le pin 5 (TRANSMIT)

Ne branchez surtout pas le fil rouge, c'est du 5V, vous grilleriez la beagle!!

Comment invoquer une méthode dont on connait le nom à l'exécution sur un dynamic?

Le mot clé dynamic en C# n'est pas nouveau, il a vu le jour avec C# 4 et pourtant il n’apparaît pas si souvent que ça dans les bouts de code que je fréquente.

Dernièrement je l'ai recroisé en utilisant SignalR; les hubs qui sont générés sont des objets dynamic.

Quoi qu'il en soit, dernièrement j'ai eu besoin d'invoquer une méthode dont le nom ne m'était connu qu'à l'exécution.
Croyez-moi, j'y ai passé un petit moment avant d'y arriver... Cela révèle vraisemblablement ma grande ignorance :)

Ce blog post prendra donc la forme d'un post-it qui me fera gagner du temps la prochaine fois que je me frotterai a cette bête-là. Si pour vous les classes Binder et CallSite n'ont plus de secret ce blog post vous semblera vraisemblablement bien terne.

Posons le problème, on me donne un objet dynamic auquel une méthode est ajoutée à l'exécution

private string sentence = "Hello world";

        public dynamic BuildObj()
        {
            dynamic myDynObj = new ExpandoObject();
            myDynObj.SayHello = new Func<string>(() => sentence);
            return myDynObj;
        }

Si j'avais connaissance de la méthode lors de la compilation je pourrais l'appeler ainsi :

[Test]
        public void CallDirectlyMethod()
        {
            dynamic myObj = BuildObj();

            var ret = myObj.SayHello();
            Assert.That(ret, Is.EqualTo(sentence));
        }

Malheureusement la signature de la méthode ne m'est connue qu'à l'exécution.
Ok, premier réflexe je sors l'attirail de la reflection.... mais les résultats restent catastrophiques :

[Test]
        public void CallMethodWithReflectionFails()
        {
            dynamic myObj = BuildObj();
            Type t = myObj.GetType();
            var method = t.GetMethod("SayHello", BindingFlags.Default | BindingFlags.Instance | BindingFlags.InvokeMethod  | BindingFlags.NonPublic);
            Assert.That(method, Is.Null);
        }

Quels que soient les bindings flags, impossible de trouver la méthode... FAIL!!

Voici, donc la combinaison magique, un savant mélange de Runtime.Binder et CallSite...

[Test]
        public void CallMethodWithCallSite()
        {
            dynamic myObj = BuildObj();

            var callSiteBinder = Binder.InvokeMember(CSharpBinderFlags.None, "SayHello",
                Enumerable.Empty<Type>(), myObj.GetType(),
                new []
                {
                    CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.None, null)
                });

            var callSite = CallSite<Func<CallSite, object, object>>.Create(callSiteBinder);
            string ret = callSite.Target(callSite, myObj);

            Assert.That(ret, Is.EqualTo(sentence));
        }

Ok, essayons de décrypter un peu ce code qui semble un peu alambiqué.
Binder.InvokeMember va nous permettre à l'exécution de pointer la bonne méthode un peu comme le ferait typeof(myObj).GetMethod()
Le premier paramètre permet de spécifier la manière dont est traité le type de retour. Dans le cas d'une Action nous aurions pu utiliser CSharpBinderFlags.ResultDiscarded. Dans notre cas, une Func, CSharpBinderFlags.None fonctionne bien.

puis viens en seconde position, évidement le nom de la méthode a appelé, passée sous forme de chaine.

En troisième position, il conviendra de fournir la liste des arguments de types à nécessaire dans le cas d'une méthode générique.

Viens ensuite le type sur lequel effectuer l'invocation, ce qui permet de pointer une surcharge.

Et finalement les informations sur les paramètres attendus et le type de retour (le premier élément du tableau);

La création du CallSite<Func<CallSite, object, object>> permet d'arrêter la signature du delegate que l'on cherche à appeler. Notez, que le dernier argument générique "object" devrait etre "string", car il représente le type de retour de la func... mais pour une raison qui m'échappe l'utilisation de string comme type de retour entraîne une erreur au runtime, alors que le retour de la func est bien affecté à une variable string à la ligne du dessous... il faut bien garder un peu de magie :)

Ok, évidemment il ne nous reste plus qu'à effectuer l'invocation, ce qui est réalisé via le code callSite.Target(callSite, myObj);

J'espère que ce post évitera quelques cheveux blancs a ceux qui se trouveront confronté au problème.