L’année 2018 débute avec une présentation sur le futur de node.js présenté par Monsieur Sebastien Pertus, Evangéliste à Microsoft France.

Celui-ci fera le déplacement depuis Paris afin de nous présenter les nouveautés proposées par node.js 8 et ce qui nous attend par la suite.

Pour en savoir plus et vous inscrire cela se passe par ici : https://www.meetup.com/fr-FR/Meetup-NET-Toulouse/events/246439541/

RDV Lundi prochain !

Cet article Prochain meetup #dotnettlse le 15 Janvier : le futur de node.js est apparu en premier sur Blog de Patrice Lamarche.

Vous pouvez consulter les slides sur mon slideshare :

J’ai rapidement abordé la problématique de mise à jour de schémas de BDD, vous pouvez également retrouver les slides de ma présentation du mois dernier aux Sql Saturdays via ce lien : http://patricelamarche.net/sqlsaturday-slides-de-ma-session-surle-versionning-et-la-mise-jour-de-bdd-avec-readyroll/

Cet article Slides de ma session sur la mise en place de pratiques agiles avec TFS/VSTS est apparu en premier sur Blog de Patrice Lamarche.

Après une session le mois dernier aux SQL Saturdays, j’aurais le plaisir de présenter une session sur l’ALM avec TFS et VSTS, lundi prochain 16 Octobre à la Cantine à Toulouse.

Au programme, retour d’expériences, bonnes et mauvaises pratiques sur la mise en place de différentes pratiques liées à l’ALM :

• Stratégies de gestion de sources
• Planification Agile
• Intégration Continue
• Déploiement Continu

N’hésitez pas à nous rejoindre pour discuter de ces sujets ! Inscription gratuite ici : https://www.meetup.com/fr-FR/Meetup-NET-Toulouse/events/243940224/

Cet article Prochain Meetup #dotnettlse le 16 octobre : l’ALM avec TFS/VSTS est apparu en premier sur Blog de Patrice Lamarche.

Vous pouvez trouvez les slides ci-dessous sur slideshare :

Cet article SQLSaturday : Slides de ma session surle versionning et la mise à jour de BDD avec ReadyRoll est apparu en premier sur Blog de Patrice Lamarche.

Bonne nouvelle ! Le SQLSaturday de 2017 ne sera pas cette année organisé à Paris, mais à Toulouse !

Cet évènement sera organisé autour de 3 tracks : DBA & Cloud-DBA, BI & Analytics, Dev & Data. Il regroupera les experts francophones les plus reconnus de la communauté Data avec les technologies Microsoft, ainsi que des speakers internationaux.

Une opportunité à ne pas manquer pour :

• tous les toulousains de profiter de cette délocalisation pour participer à l’évènement à moindre frais
• pour les nordistes habitant au nord de Montauban de découvrir notre magnifique ville de Toulouse !

Vous pouvez consulter une première version du planning de cette journée ici :

Vous pourrez m’y retrouver puisque j’aurais l’opportunité de présenter une session sur la mise en place d’intégration continue et de déploiement continue de vos bases de données SQL Server, grâce à ReadyRoll de Redgate (disponible à présent dans l’édition Entreprise de VS 2017), et VSTS.

L’inscription est gratuite, venez nombreux en vous inscrivant dès maintenant (les places sont limitées) à cette adresse : https://www.sqlsaturday.com/658/registernow.aspx

Pour plus d’infos : http://www.sqlsaturday.com/658/EventHome.aspx

Cet article RDV pour le SQLSaturday le 16 Septembre à Toulouse ! est apparu en premier sur Blog de Patrice Lamarche.

Je vous avais indiqué il y a quelques jours que Microsoft souhaitait proposer des images Docker de Nano Server 2x fois plus petites qu’actuellement, et bien l’éditeur propose les premiers résultats de ses efforts via son programme insiders et les résultats sont très impressionnants !

Sur le repository dédié : https://hub.docker.com/r/microsoft/nanoserver-insider/tags/ on peut en effet apprécier la diminution impressionnante de l’image compressée qui passe de 383Mo à 78Mo !

Une fois décompressée sur le disque, celle-ci pèse moins de 200Mo contre 1Go actuellement, plus qu’une réduction de 50%, l’image de Nano Server vNext pèse donc pour le moment 20% de l’image actuelle !

Un excellent résultat qui permettra de gagner fortement en crédibilité dans le domaine des conteneurs.

Cet article Nano Server vNext : Windows en 78Mo est apparu en premier sur Blog de Patrice Lamarche.

Comme vous avez pu le découvrir via ma série de posts dédié à Docker :

• L’essentiel sur Docker et les conteneurs Windows
• L’essentiel de Docker : Débuter par la pratique
• Visual Studio 2017 et docker : de réelles avancées
• Docker : Quels scénarios pour un éditeur de logiciels ?

A partir de Windows Server 2016, Microsoft propose une nouvelle édition de Windows nommée Nano Server. Cette édition permet d’avoir une image Docker 10 fois plus légère qu’une image Windows Server Core grâce à un refactoring important et une suppression de tous les services inutiles pour cette édition destinées à être utilisée au sein de conteneurs.

Cela avait été annoncé discrètement durant la Build, puis plus officiellement la semaine dernière, l’investissement de Microsoft continue dans cette même direction et va même plus loin puisque l’éditeur annonce que ses efforts vers cette nouvelle édition sont une priorité, et que la prochaine édition de Nano Server permettra de faire des images plus de 2x plus petites qu’actuellement (actuellement 300 Mo compressée) avec donc à la clé des chargements plus rapides, et bien sûr une densité de conteneurs sur vos machines hôtes plus importante.

Rendez-vous en automne (merci le nouveau rythme de livraison bi-annuel de Windows Server ) pour le résultat final !

Pour plus d’infos :

• Delivering continous innovation with Windows Server
• L’essentiel sur Docker et les conteneurs Windows

Cet article Nano Server vNext permettra d’avoir des images Docker 2x plus petites est apparu en premier sur Blog de Patrice Lamarche.

Le nouvel épisode concerne la tâche de zipalign indispensable l’optimisation de vos packages et pour s’assurer du bon fonctionnement de vos applications sur les devices.

Lors de l’activation de cette tâche sur votre processus de build vous pouvez vous retrouver avec l’erreur suivante :

##[error]ANDROID_HOME is not set
##[error]Return code: 1

Vous l’aurez vite compris, il est ici nécessaire de créer une nouvelle variable d’environnement nommée ANDROID_HOME contenant le chemin du SDK d’Android (ex : C:\Program Files (x86)\Android\android-sdk). Redémarrez ensuite les agents de build pour que la modification soit prise en compte.

A bientôt pour une nouvelle erreur Xamarin

Cet article [Tips] Erreur ANDROID_HOME is not set lors du zipalign d’un package Xamarin Android est apparu en premier sur Blog de Patrice Lamarche.

Une erreur “jarsigner failed. spawn jarsigner ENOENT” peut être levée.

En version détaillée dans mon cas :

##[error]Error: C:\Program Files\Microsoft Team Foundation Server 15.0\Search\Java\jre1.8.0_111\bin\jarsigner failed. spawn C:\Program Files\Microsoft Team Foundation Server 15.0\Search\Java\jre1.8.0_111\bin\jarsigner ENOENT

Comme l’indique l’erreur ENOENT, quelqu’un manque à l’appel, et dans le cas présent c’est tout simplement le jarsigner.exe qui est absent du dossier dans lequel TFS recherche l’outil de signature de package java.

TFS cherche en effet étrangement cet outil dans l’environnement java installé avec Code Search, la nouvelle fonctionnalité de TFS qui permet d’indexer le code présent dans les repositories et d’effectuer des recherches. Cet environnement ne comprenant pas l’outil jarsigner, toute signature est impossible depuis vos builds.

Vous pouvez donc rencontrer un conflit entre la fonctionnalité Code Search et les tâches de signature de Xamarin Android.

Pour corriger le problème, vous devez modifier la variable d’environnement JAVA_HOME afin de l’uniformiser avec vos autres variables liées à Java, dans mon cas :

Redémarrez ensuite les services windows correspondant à vos agents de builds afin que cette modification soit prise en compte.

Cet article [Tips] Signature package Xamarin Android en erreur : jarsigner failed ENOENT est apparu en premier sur Blog de Patrice Lamarche.

J’ai eu cette désagréable surprise en effectuant un simple Directory.GetFiles(monpath, « *.pdf »)

La documentation https://msdn.microsoft.com/fr-fr/library/ms143316(v=vs.110).aspx indique que lorsque l’on fait un GetFiles avec un filtre sur une extension contenant 3 caractères, tous les fichiers ayant une extension débutant par cette extension sont renvoyés.

When you use the asterisk wildcard character in a searchPattern such as « *.txt », the number of characters in the specified extension affects the search as follows:

• If the specified extension is exactly three characters long, the method returns files with extensions that begin with the specified extension.For example, « *.xls » returns both « book.xls » and « book.xlsx ».

Ainsi un Directory.GetFiles(monpath, « *.pdf ») renvoie tous les fichiers qui ont une extension qui débute par .pdf. Ainsi les fichiers “.pdf” mais également les fichiers ayant une extension “.pdfa” sont renvoyés.

Cette règle indiquée dans la documentation est vraie mais uniquement si le format 8.3 des fichiers est activé !

La gestion du format 8.3 des fichiers peut en effet être désactivé pour des raisons de performances (cf https://blogs.technet.microsoft.com/josebda/2012/11/13/windows-server-2012-file-server-tip-disable-8-3-naming-and-strip-those-short-names-too/). Si tel est le cas, la méthode GetFiles aura un comportement différent, et ne renverra pas la même liste de fichiers. La recherche sera effectué en respectant exactement le filtre sans prendre en compte les extensions de plus de 3 caractères.

Dans mon cas, mon application étant déployée sur deux serveurs différents ayant deux paramétrages différents, des résultats différents sont renvoyés avec malheureusement un impact fonctionnel malencontreux

Pour savoir si votre lecteur a le format 8.3 d’activé, faites un dir /X sur un dossier qui contient un ou plusieurs fichiers ayant un nom long, et regardez si une colonne contenant le nom court apparaît. Si ce n’est pas le cas, le format 8.3 est désactivé.

Format 8.3 activé :

Format 8.3 désactivé :

Les noms de fichiers sont longs (dépassent 8 caractères) et n’ont pas d’équivalence au format court, le format 8.3 est donc désactivé sur ce lecteur

Si vous souhaitez avoir un même comportement quel que soit le disque dur, il est donc nécessaire d’effectuer un second filtre de ce type :

Directory.GetFiles(directory, « *.pdf »).Where(item => item.EndsWith(« .pdf »));

Cet article [Tips] Directory.GetFiles renvoie des résultats differents en fonction des machines est apparu en premier sur Blog de Patrice Lamarche.