Quand on utilise MVVM, il faut se rappeler que l’on exploite un pattern qui a plus de 10 ans. En 10 ans, il y a d’énormes évolutions dans le monde du développement. Que ce soit dans le bon ou le mauvais sens.

Régulièrement, il m’arrive de tomber sur une implémentation qui donne bien du fil à retordre au Garbage Collector. Tellement, qu’il ne peut pas faire correctement son travail.

HttpUtility, WebUtility et tous leurs semblables font régulièrement l’objet de débats. L’un serait mieux pour ceci, l’autre pour cela. De tout temps, il y a eu des développeurs pour aller faire du reverse engineering sur leurs méthodes (ou tout simplement aller voir le code sur GitHut) pour savoir ce qu’elles avaient dans le ventre.

Aujourd’hui, je tiens à rappeler que comme pour un certain WebClient, le sujet, ne devrait plus être d’actualité. La seule vraie question que l’on devrait se poser est : « Est-ce que cette classe sera disponible sur ma plateforme pour mon projet ? ».

Là il n’y a qu’une réponse possible : System.Net étant le namspace présent sur toutes nos plateformes, il convient de privilégier les classes qui s’y trouvent.

Donc non, on n’utilise pas WebUtility pour se débarrasser de System.Web (et autres namespaces), mais plutôt pour prépare demain et avoir un code qui marchera partout et qui migrera sans problèmes (.net standard, .net Framework, .net Core, et donc UWP, Xamarin, ...).

Si vous travaillez uniquement sur .net Core, il est évident que vous n’avez pas Sytem.Web. Ce n’est pas pour autant qu’il faut tout le temps cracher dessus ;)

Une fois la certification Xamarin Developer obtenue, celle-ci est valable un an. Pour pouvoir la renouveler, il faut avoir un abonnement actif à la date anniversaire de celle-ci et avoir passé 6 nouveaux cours (ou cours actualisés).

Seul problème, jusqu’ici il n’était pas facile de savoir quel cours avait été pris en compte pour le renouvellement. Il était donc un peu ardu de connaitre le travail restant à accomplir.

Depuis peu, le site Xamarin University a été mis à jour afin que l’on dispose d’un suivi. Celui-ci est disponible via la page profile et ressemble à ci :

6 sur 6, c’est bon pour moi cette année ;)

Si comme moi, vous avez utilisé Visual Studio Team Services (VSTS) depuis le début, vos services sont certainement hébergés aux États Unis. Ceci n’est pas toujours des plus judicieux. Surtout si vous liez VSTS à d’autres services hébergés en Europe ou un autre continent que le continent américain.

Heureusement, il est possible de déplacer les services VSTS d’une zone géographique à une autre.

En soi, il n’existe pas de commande disponible via le site VSTS, ni même de commande PowerShell. Il existe cependant un processus tout simple, mais peu connu.

Depuis longtemps déjà, il est possible d’utiliser IIS Express en 64bits, sans avoir à s’arracher les cheveux.

Pour ce faire, on peut rechercher l’option via le menu Tools > Options. Ou alors, passer par le Quick Launch et rechercher par exemple IIS 64.

Ceci permet d’accéder aux options des projets Web. Pour utiliser IIS Express en 64 bits, il suffit de cocher la première case.

Pour revenir à la version 32bits, il suffit de décocher la case. IIS Express doit être fermé après chaque changement pour que Visual Studio puisse lancer la version définie via cette option.

Simple et sans complication, contrairement à ce qui m’a encore été dit récemment ;)