Archives de catégorie : .net

Slides du meetup sur Visual Studio App Center

Vous pouvez retrouver les slides de la présentation que nous avons faite hier soir avec Thomas Bureau du colombier sur la mise en place de Visual Studio App Center au sein de Chausson Matériaux. N’hésitez pas à me contacter pour toute question et/ou feedback sur cette présentation.

Rendez-vous en Septembre pour la rentrée du meetup .net Toulouse.

News de la semaine #22

Suite à un changement de modèle et d’ergonomie de Scoop.it, j’abandonne la plate-forme et reviens donc aux news de la semaine qui seront hebdomadaires si l’actualité le permet.

image

.net
.net Core 2.1 est disponible. A noter la suppression de l’intégration directe dans IIS qui était initialement prévue Sad smile
Announcing ASP.NET Providers Connected Service Visual Studio Extension

ALM
Mise à jour de Git suite à une vulnérabilité critique

Nouveautés de Visual Studio App Center pour le mois de Mai

Azure
A Penny Saved is a Ton of Serverless Compute Earned  : Un billet très intéressant sur le coût de l’offre serverless

Web
Evolving Chrome’s security indicators : Warning, Chrome va modifier l’affichage des sites non-https

Announcing TypeScript 2.9

Misc
Maintaining Notepad is not a full-time job, but it’s not an empty job either

Follow the CAPEX: Separating the Clowns from the Clouds : Billet intéressant sur la réalité des investissements dans le cloud des différents fournisseurs de services (Microsoft, Amazon, Oracle, IBM, etc.)

Comprendre le positionnement de Blazor

Backend, Frontend, FullStack

Software is eating the world, et le “web is eating software” depuis quelques années maintenant.

Cette omniprésence du web s’accompagne d’un nombre d’évolutions croissant et différents changements d’architectures.

D’un monde orienté quasi intégralement côté backend, où la consommation des données et la génération de l’UI (les vues) se faisait côté serveur. Nous nous sommes orientés vers un monde orienté services, où pour des raisons d’ergonomie et de vitesse de plus en plus de responsabilités sont déportées côté client.

Le schisme entre le backend et le frontend

Ainsi les vues, et la consommation de données exposées par des services se font le plus souvent côté client.

Pour accompagner ce transfert de responsabilité tout un tas de nouvelles libraires, frameworks et outils sont arrivés : jQuery, AngularJS, Angular, Vue, React, npm, bower, gulp, webpack, etc.

image

L’unification technologique que l’on pouvait avoir côté serveur, se complète d’une multitude de nouvelles technologies côté client.

Les développeurs doivent donc maitriser des technologies et langages très différents entre le côté backend et le côté frontend, pour avoir le profil fullstack ci-souvent souhaité.

Illustration dans le monde Microsoft

Dans l’écosystème Microsoft, cette séparation entre le front et le back peut être illustré par l’évolution d’ASP.net.

Au tout début de .net, l’essentiel des développeurs Microsoft étant des développeurs Windows, l’éditeur proposa une technologie de développement web adaptée : ASP.net Webforms. Reproduisant presque à l’identique le modèle de développement Windows, la technologie de développement web était la solution idéale pour inciter ce public à passer au web. Comme beaucoup de technologies de l’époque, les projets ASP.net webforms se concentraient quasi-exclusivement côté serveur. A l’arrivée d’Ajax, Microsoft continua sur cette lancée en proposant ASP.net Ajax et un toolkit associé permettant de bénéficier du développement côté client… sans faire de développement client ! Merci l’update panel et consors !

Afin de proposer un réel modèle de développement Web, ASP.net MVC fut ensuite proposé avec une intégration native de différentes technologies frontend. Le javascript et son écosystème prenant une place prépondérante au sein de ce type d’applications.

Incompréhensions, antipatterns

Nombre d’incompréhensions et d’antipatterns sont issus de toutes ces évolutions et de cette séparation entre le frontend et le backend :

  • L’incompréhension de la différence entre une librairie et un framework. Non, AngularJS n’est pas la suite logique de JQuery, utiliser un framework n’est pas anodin. C’est un choix technique majeur, qui définit un couplage très fort vers une certaine technologie
  • La non-compréhension que la plupart des frameworks frontend, sont des framework SPA, qui n’ont pas été conçus à la base pour être intégrés dans des sites web « classiques » multi-page. Ce n’est pas pour rien si ces frameworks proposent un grand nombre de fonctionnalités qui font doublon avec les frameworks serveurs traditionnels (vue, binding, routing, etc.)
  • Une incompréhension sur l’utilisation de ces frameworks dans des applications multi-page. Oui il peut être pratique d’utiliser des vues côté client pour afficher des données issues de services web, mais il faut être très clair sur la séparation des responsabilités.

Des décisions compliquées

Impact de cette explosion de technologies, et de changements de frameworks à la mode :

  • Il est compliqué de faire les bons choix techniques et d’assurer une bonne pérennité de ses applications
  • Dans un monde agile où l’on recherche le plus souvent des développeurs polyvalents « fullstack », le volume de compétences à avoir pour être « fullstack » est très (trop) important. Les développeurs peuvent avoir tendance à privilégier le côté back, ou le côté front en fonction de leurs intérêts.

Nombre de développeurs ne semblent pas trop effrayés par toutes ces évolutions du web, et s’intéressent à toutes les nouvelles technos à la mode.

Mais d’autres refusent cet écosystème à l’évolution archaïque et anarchique, en prenant une solution qui peut sembler radicale et vieux-jeu mais qui est tout à fait pertinente si l’on privilégie la pérennité.

VanillaJS

Le no-framework côté frontend qui consiste à n’utiliser qu’une librairie comme jQuery, soit aucune librairie tout court prend petit à petit de l’importance. Préconisé/formalisé par le mouvement Vanilla JS, ce type de décision ne doit pas être vu comme rétrograde, mais comme raisonnable pour ceux qui souhaitent privilégier la pérennité des développements.

Car oui, il n’est pas indispensable ni obligatoire d’utiliser Angular, React, Vue, ou autre framework pour développer une application web ! Tout dépend des besoins, et des critères des choix des technologies, du curseur que l’on place entre la spécialisation/complexité de l’implémentation proposée, et la pérennité de la solution finale.

Une première solution pour éviter cette séparation entre le front et le back, est d’utiliser le même langage des deux côtés : Javascript.

Blazor : ASP.net MVC FullStack

Blazor est une autre piste permettant de ne pas subir cette séparation. Blazor est pour le moment uniquement une « simple » expérience gérée par l’équipe ASP.net et non pas un produit final.

L’idée est assez simple, proposer un socle technologie simple permettant de créer des pages web en capitalisant sur ses compétences .net.

Avoir comme unique solution d’utiliser le langage javascript côté client et côté serveur serait un risque pour Microsoft de perdre toute pertinence dans le monde de développement web (à l’exception notable de TypeScript).

Microsoft propose donc avec Blazor de capitaliser ses compétences .net, en utilisant le langage C# et le moteur de vue Razor côté backend comme actuellement, mais surtout à présent également du côté frontend.

Une technologie qui pourrait être la solution idéale pour éviter le javascript « madness » et ne plus avoir besoin de se baser essentiellement sur cet écosystème.

Le tout en respectant bien évidemment les standards du web grâce à l’utilisation de WebAssembly et asm.js.

L’exécution de code C# côté client au sein d’un navigateur est rendu possible grâce à une implémentation du runtime .net en WebAssembly développée par l’équipe Xamarin.

Pour les anciens navigateurs qui ne supportent pas WebAssembly, asm.js est utilisé comme fallback afin d’être exécuté de manière universelle.

Comme il n’est pas utile de répéter ce qui est déjà présent online, vous pouvez en savoir plus d’un point de vue technique via ce post : https://blogs.msdn.microsoft.com/webdev/2018/03/22/get-started-building-net-web-apps-in-the-browser-with-blazor/

Un positionnement osé ?

Inutile de le repréciser cette technologie s’adresse avant tout aux développeurs .net, en proposant une alternative à javascript.

Bien que reposant sur les standards, proposer une alternative à javascript est plutôt osé. En proposant une solution rassurante et uniquement adaptée à sa population de développeurs .net, Microsoft risque de donner de nouveau une image d’éditeur qui ne s’intègre pas à l’écosystème actuel en proposant ses propres solutions. Cela devrait néammoins être atténué par l’approche du « nouveau » Microsoft : le projet est open-source sur github, et respecte les standards.

Mais comme souvent, cette nouvelle solution n’est pas exclusive mais complémentaire. Il ne faut pas voir Blazor comme étant une solution remplaçant ASP.net MVC mais comme une solution complémentaire à ASP.net MVC.

Pour caricaturer un petit peu, si vous êtes dans une startup ou chez un éditeur de logiciels qui privilégie l’utilisation des dernières technos pour satisfaire à de nouveaux besoins, vous pouvez utiliser ASP.net MVC « classique » et tout l’écosystème javascript. Si vous travaillez pour un éditeur ou une entreprise en interne, où la pérennité des développements est essentielle et où le coût d’utilisation de l’écosystème Javascript et le coût de la gestion de ces compétences n’est pas acceptée ou souhaitable, vous pourrez potentiellement vous orienter vers Blazor.

Slides de ma session sur la mise en place de pratiques agiles avec TFS/VSTS

imageJ’ai eu le plaisir de présenter hier soir une session au meetup .NET Toulouse sur l’ALM avec TFS/VSTS et plus précisément sur la mise en place de “vraies” pratiques agiles grâce à TFS et VSTS.

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 : https://patricelamarche.net/sqlsaturday-slides-de-ma-session-surle-versionning-et-la-mise-jour-de-bdd-avec-readyroll/

Nano Server vNext : Windows en 78Mo

Microsoft loves Docker

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 !

docker nano server

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.

[Tips] Erreur ANDROID_HOME is not set lors du zipalign d’un package Xamarin Android

Dans la série des erreurs que vous pouvez rencontrer lors de la mise en place d’une build Xamarin Android, après : [Tips] No agent could be found with the following capabilities AndroidSDK, MSBuild, Xamarin.Android, JDK puis, [Tips] Signature package Xamarin Android en erreur : jarsigner failed ENOENT

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

image

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 Smile

[Tips] Signature package Xamarin Android en erreur : jarsigner failed ENOENT

Lors de la mise en place d’une build Xamarin Android avec Team Foundation Server, vous pouvez vous retrouver avec une erreur lors de l’étape de Signature de votre package.

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

image

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 :

image

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

[Tips] Directory.GetFiles renvoie des résultats differents en fonction des machines

Rien n’est simple ni facile en informatique, et le jour où j’ai constaté qu’un Directory.GetFiles tout bête me renvoyait des résultats différents pour une même liste de fichiers présents en local sur ces serveurs n’a fait que confirmer cet état de fait !

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 Smile

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é :

clip_image001

Format 8.3 désactivé :

clip_image002

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 »));

[Tips] Arrêter une collection TFS afin d’indiquer un message de coupure de service

Si après une migration de votre serveur TFS “On Prem” vers une nouvelle machine (et si vous n’utilisez malheureusement pas d’alias DNS pour accéder à celui-ci) et que vous souhaitez ne pas couper brutalement votre serveur TFS et ainsi laisser l’équipe avec des messages d’erreur bizarres s’ils ouvrent des projets mappés avec l’ancien serveur, vous pouvez utiliser une fonctionnalité de TFS : l’arrêt de collection.

Ainsi même si vous n’utilisez qu’une seule collection de Team Projects vous pouvez tout à fait l’arrêter via la console d’administration de TFS :

image

Lorsque vous l’arrêtez vous pouvez saisir un message d’information à destination de tous les utilisateurs de cette collection :

image

Ce message est alors repris dans Visual Studio lorsque vous connectez au Team project, mais surtout également depuis le Team Explorer pour chaque action effectuant un accès serveur à la collection :

image

Nouveautés de Visual Studio 2017 : #3 Améliorations sur l’integration continue

S’il y a bien un thème important au niveau des avancées de l’offre ALM de Microsoft il s’agit bien de l’intégration continue et de la livraison voire déploiement en continu.

Nous y reviendrons au travers de plusieurs posts liés à TFS et VSTS, mais commençons aujourd’hui par deux petites nouveautés liées à Visual Studio 2017.

1ère nouveauté qui permettra de combler l’utilisation d’outil tiers tel que le logiciel Siren of shame par exemple, l’intégration d’un notifier de build directement au sein de la barre d’état de Visual Studio 2017.

Ainsi si après un push ou la soumission d’un PR vous souhaitez connaitre l’état de la build liée à votre/vos commits, plus besoin de se déplacer dans le Team Explorer ou encore dans le portail web, vous pouvez travailler sur une autre tâche et attendre patiemment que Visual Studio 2017 vous indique que tout est OK, ou vous signale que vous devez intervenir en urgence pour corriger le tir :

image

Autre nouveauté pratique, l’intégration de l’error list directement au sein du panneau des modifications de sources. Ainsi les informations de Warning, et d’erreur de compilation sont placées idéalement et mises en avant même que vous effectuiez vos commit :

image 

Ces deux nouveautés sont proposés via une extension qui est pour le moment en preview, et qui sera disponible à terme dans l’édition Entreprise de Visual Studio.

Vous pouvez dores et déjà l’utiliser en l’installant : https://marketplace.visualstudio.com/items?itemName=VSIDEDevOpsMSFT.ContinuousDeliveryToolsforVisualStudio