Un autre élément vient à .NET Core: Microsoft gardera le runtime patché automatiquement

  • FrançaisFrançais


  • Microsoft ajoutera les environnements d’exécution .NET Core et .NET 5.0 au service de mise à jour intégré à Windows – mais les entreprises doivent y participer et les applications doivent être déployées à l’aide d’un environnement d’exécution partagé pour que cela soit efficace.

    Ces environnements d’exécution .NET, contrairement à l’ancien .NET Framework, ne sont pas traités comme des mises à jour du système ou du système d’exploitation. Selon Jamshed Damkewala, principal responsable de l’ingénierie de Microsoft, .NET Core et son successeur .NET 5.0 sont considérés comme des «produits indépendants» et ne seront donc mis à jour que si les utilisateurs optent pour Microsoft Update, qui est distinct de Windows Update.

    Cela contraste avec le .NET Framework, l’ancien .NET Windows uniquement, qui est traité comme un composant système et corrigé en conséquence.

    Ce changement s’est fait attendre depuis longtemps, Microsoft apparemment indécis sur la meilleure façon de résoudre le problème de la mise à jour du runtime lorsque des failles de sécurité sont découvertes.

    Les développeurs doivent publier des applications .NET en tant que «dépendantes du Framework» afin de bénéficier des correctifs d’exécution automatique

    Il y a six ans, peu de temps après l’annonce de .NET Core, Jay Schmelzer de Microsoft nous a dit: “On ne sait pas exactement comment cela fonctionnera parce que nous n’avons pas encore décidé. Nous voulons déterminer avec la communauté quelle est la meilleure approche à travers Windows, Linux et Mac. “

    Un autre fardeau?

    Le dilemme est que le fait que le système mette à jour le runtime signifie que les applications qui utilisent en commun ce runtime peuvent en théorie casser; sans mettre à jour, il déplace le fardeau sur les développeurs et les administrateurs de garder les yeux sur les failles nouvellement découvertes et de corriger manuellement les systèmes.

    Microsoft avait fait des efforts pour éviter le problème d’antan «DLL Hell», où une mise à jour requise pour faire fonctionner l’application A pouvait également interrompre l’application B, en adoptant une politique côte à côte même pour les environnements d’exécution installés de manière centralisée.

    Avec .NET Core, toutes les versions de fonctionnalités (qui ont des numéros de version mineurs différents) sont installées côte à côte et corrigées séparément. Les versions de correctif, qui se distinguent dans le système de Microsoft par le troisième numéro de la version, par exemple de 3.1.0 à 3.1.1, remplaceront les installations existantes. Les versions de correctif incluent cependant des correctifs non liés à la sécurité et des problèmes de compatibilité sont possibles.

    Câblage réseau COMPLET

    Démêler .NET Core: Open source pour Windows, Mac, Linux

    LIRE LA SUITE

    Les applications .NET Core ont plusieurs modes de déploiement différents, y compris dépendants du framework (utiliser un runtime partagé) ou autonomes (regrouper le runtime avec l’application). Comme vous vous en doutez, seuls les déploiements dépendants du framework seront corrigés par Microsoft Update. «NET Core Runtime (distribué avec votre application) ne peut être mis à niveau qu’en publiant une nouvelle version de votre application», expliquent les documents.

    Le changement est le bienvenu, même si un intervenant a fait remarquer: “Le fait que cela doit être un OPT-IN, le rend inutile dans un environnement non professionnel.”

    Tout dépend du nombre d’utilisateurs optant pour Microsoft Update par opposition à Windows Update lorsqu’ils sont présentés avec ces options.

    Les développeurs aiment l’idée de déploiements autonomes; ils savent exactement quel code sera exécuté et il y a moins de dépendances. Cette approche peut fonctionner pour les applications fréquemment mises à jour, comme celles qui sont activement maintenues via un pipeline CI / CD (Continuous Integration / Continuous Delivery).

    Dans d’autres scénarios cependant, il est plus difficile de plaider en faveur de déploiements autonomes; le risque de détection de problèmes de sécurité lors de l’exécution peut être plus grave que le risque de rupture de l’application. ®

    Laisser un commentaire

    Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *