Partager via

Mettre à niveau les extensions Windows Admin Center existantes vers Angular 11

  • S’applique à: ✅ Windows Admin Center, ✅ Windows Admin Center Preview

Windows Admin Center est en train de passer à Angular 11.0 ! Cette mise à niveau apporte les dernières fonctionnalités, la sécurité et les performances, et nous sommes ravis de l’avoir à votre disposition. Jusqu’à présent, le shell de Windows Admin Center a été mis à niveau et c’est à votre tour de mettre à jour vos extensions. Suivez les étapes décrites dans ce document pour mettre à jour votre extension.

Si vous rencontrez des problèmes au cours de ce processus, contactez votre contact Microsoft qui vous aidera à acheminer la demande.

Étapes préliminaires

Avant de commencer la mise à niveau vers Angular 11, vous devez configurer votre environnement de développement avec le dernier shell et les outils de développement de Windows Admin Center. Procédez comme suit avant de passer au processus de mise à niveau :

  1. Installez la dernière version de Windows Admin Center en mode développement (msiexec /i WindowsAdminCenter<version>.msi DEV_MODE=1) avec l’interpréteur de commandes mis à niveau. Contactez votre contact Microsoft si celui-ci ne vous a pas été fourni.
  2. (Recommandé) Créez une features/ng11 branche dans le dépôt.
  3. (Recommandé) Mettre à jour version.json la version vers (N+1).0.0.
  4. Dans une console PowerShell, assurez-vous de basculer vers la version de Node respective pour votre version Angular (pour plus d’informations, consultez Utilisation de deux branches de shell pour plus de détails). Pour Angular 11, exécutez nvm use 12.18.3. Fermez le terminal pour que cette modification prenne effet.
  5. Nettoyez le dossier pour éviter les node_modules conflits npm.

Processus de mise à niveau automatisé

Téléchargez et installez les outils CLI de Windows Admin Center en les exécutant npm install -g @microsoft/windows-admin-center-sdk@experimental si vous ne l’avez pas déjà fait avant de passer aux étapes suivantes.

  1. Au niveau racine du dépôt, exécutez wac upgrade --audit=false --experimental.

    • Si vous travaillez sur un référentiel d’extensions qui est consommé par d’autres extensions, incluez également l’indicateur --library .

    Si l’indicateur de bibliothèque a été utilisé, modifiez la propriété pour qu’elle namesrc/package.json soit unique à l’extension.

  2. (Conditionnel) Si le dépôt d’extension a des dépendances sur un autre package d’extension, vous devrez choisir manuellement la nouvelle version angulaire de cette extension (par exemple, msft-sme-certificate-manager a une dépendance sur msft-sme-event-viewer. Les outils automatisés ne mettront pas à jour msft-sme-event-viewer la version, elle doit être mise à jour manuellement.) Assurez-vous également de spécifier le niveau de dossier '/dist' sur toutes les importations à partir d’extensions, toute importation de niveau inférieur ou supérieur ne fonctionnera pas (par exemple, import { foobar } from '@msft-sme/event-viewer' il faudrait la remplacer par import { foobar } from '@msft-sme/event-viewer/dist'.)

  3. Ouvrez app-routing.module.ts et modifiez tous les appRoutes dont le format ./folder-name/file-name#ModuleClass est .() => import('./folder-name/file-name').then(m => m.ModuleClass) S’il y a d’autres routing.module.ts fichiers, ils devront également être mis à jour de cette manière.

  4. Supprimer le UpgradeAudit.txt fichier. Il est généré automatiquement pour votre référence, mais n’a pas besoin d’aller dans le dépôt.

  5. Parcourez les fichiers suivants et remplacez toutes les instances de @msft-sme par @microsoft/windows-admin-center-sdk:

  • ./angular.json
  • ./gulpfile.ts/common/e2e.ts
  • ./gulpfile.ts/common/resjson.ts
  • ./src/polyfills.ts
  • ./src/test.ts
  1. Il est probable qu’il y aura des erreurs non résolues à la suite des étapes que vous avez effectuées. Passez aux étapes de génération.

Étapes de génération

À ce stade du processus de mise à niveau, votre dépôt d’extension est prêt à être généré et le processus de débogage peut commencer. Procédez comme suit :

  1. Exécutez gulp build.
  2. Méfiez-vous des erreurs de linting et de compilation.
  3. Corrigez ces erreurs et répétez les étapes 1 à 3 si nécessaire.
  4. Une fois toutes les erreurs de génération corrigées, validez vos modifications et passez aux étapes d’exécution.

Erreurs de build difficiles à diagnostiquer

Certaines des erreurs que vous pouvez rencontrer lors du débogage à l’étape de génération peuvent être difficiles à diagnostiquer. Voici deux des erreurs les plus courantes et difficiles à diagnostiquer et comment les atténuer :

  • NG6002 : Apparaît dans le fichier NgModule.imports d’AppModule, mais n’a pas pu être résolu en une classe NgModule

    • Ce type d’erreur se produit au moment de la génération, généralement avant que le référentiel mis à niveau n’ait été généré avec succès au moins une fois. Pour résoudre le problème, exécutez ng serve --prod, après quoi ces erreurs ne devraient plus apparaître lors de la construction.

  • L’interface étend incorrectement une autre interfaceL’image représentant l’interface étend de manière incorrecte une autre erreur d’interface.

    • Cette erreur se produit lors de l’étape inlineCompile de « gulp build » et se produit à la suite d’une incompatibilité entre les versions du package téléchargé et ce @types/jasmine dont le @types/jasminewd2 package a besoin. Cette erreur peut être résolue en supprimant le @types/jasminewd2 package.

Noms de fichiers du bundle de sortie

Lors de la création de votre extension, vous pouvez rencontrer des problèmes en raison des noms de fichiers dans votre bundle. Pour éviter ces problèmes, portez une attention particulière aux champs suivants :

  • Le hachage de sortie doit être activé. Lorsque le hachage de sortie est activé, des noms de fichiers uniques sont générés pour chaque build de l’extension. Si cette option n’est pas activée, il se peut que vous ne puissiez pas voir les modifications apportées à votre extension lors de l’affichage dans le navigateur en raison de noms de fichiers en double.
    • Pour activer la ligne de commande à partir de ce champ, ajoutez l’indicateur --output-hashing à une ng build commande.
    • Pour activer ce champ directement à partir de votre dépôt, accédez à votre fichier angular.json et recherchez-le sous Configurations outputHashing de production.
  • Les blocs nommés doivent être désactivés. Lorsque les blocs nommés sont activés, chaque fichier de bundle inclut son nom de fichier de module d’origine. Bien que cela puisse sembler utile, cela se traduit souvent par des noms de fichiers incroyablement longs qui peuvent entraîner des erreurs dans le flux d’extension Windows Admin Center.
    • Pour désactiver ce champ à partir de la ligne de commande, ajoutez l’indicateur --named-chunks à une ng build commande.
    • Pour désactiver ce champ directement à partir de votre dépôt, accédez à votre fichier angular.json et recherchez-le sous Configurations namedChunks de production. Définissez ce champ sur false.

Étapes d’exécution

Maintenant que vous avez corrigé toutes les erreurs de build dans votre extension, vous êtes prêt à exécuter votre extension et à résoudre tous les problèmes d’exécution. Suivez les étapes ci-dessous pour exécuter votre extension :

  1. Chargez l’extension avec gulp serve --port <port> --prod --aot.
  2. Dans le navigateur, recherchez les problèmes d’exécution de l’extension, tels que :
    • Page(s) d’extension ne se charge pas
    • Éléments manquants dans la ou les pages d’extension
    • Erreurs de console
    • Tout ce qui a l’air bizarre ou qui se comporte étrangement
  3. Corrigez tous les problèmes d’exécution que vous avez découverts.
  4. Lorsque l’extension a été stabilisée, validez vos modifications.

Lorsque vous avez terminé ces étapes, passez à la création d’une branche principale.

Création d’une branche principale

Une fois que toutes les erreurs de linting, de compilation et d’exécution ont été corrigées, vous êtes prêt à terminer la mise à niveau de votre extension. Pour ce faire, nous devons créer une nouvelle branche dans le dépôt d’extensions. Suivez ces étapes pour terminer la mise à niveau de votre extension :

  1. Assurez-vous que vous êtes prêt à terminer le processus de mise à niveau et que tout fonctionne comme prévu dans la branche des fonctionnalités.
  2. Créez une nouvelle branche nommée « main » dans le dépôt.
  3. Créez une demande de tirage à partir de la branche features/ng11 qui fusionne avec main.
  4. Lorsque vous êtes prêt, remplissez le PR.
  5. Félicitations, vous avez réussi à mettre à jour une extension !

Publication de votre extension mise à niveau

Une fois que votre extension a été testée en mode bureau et service Windows Admin Center, envoyez un e-mail à pour wacextensionrequest@microsoft.com coordonner la publication de votre extension mise à niveau.

Travailler avec deux branches de la coquille

La mise à niveau de l’interpréteur de commandes Windows Admin Center a entraîné de nombreuses modifications environnementales. L’un de ces changements est l’utilisation de Node 12.18.3 par rapport à la version précédente 10.22.0. Ces versions sont incompatibles et vous devez basculer votre version globale pour exécuter des commandes de génération dans chaque environnement.

Pour gérer vos versions de Node, nous vous suggérons d’utiliser Node Version Manager : https://github.com/coreybutler/nvm-windows

Suivez les instructions pour installer nvm-windows sur votre machine.

Une fois installé, vous pouvez préparer votre environnement en exécutant les commandes suivantes :

nvm install 12.18.3
nvm use 12.18.3
npm i -g gulp-cli
npm i -g @angular/cli
npm i -g vsts-npm-auth
npm i -g typescript

nvm install 10.22.0
nvm use 10.22.0
npm i -g gulp-cli
npm i -g @angular/cli
npm i -g vsts-npm-auth
npm i -g typescript

Cela configurera votre environnement Node pour le développement avec la nouvelle et l’ancienne version d’Angular.

Basculement de la version de Node

La version de Node que vous utilisez peut être activée à l’aide de PowerShell.

La nvm list commande peut être utilisée pour répertorier les versions de nœuds installées.

La nvm use <version> commande peut être utilisée pour basculer rapidement entre les versions de nœud.

Vous pouvez trouver une liste complète des versions de Node, Angular et Typescript qui vont ensemble ici : Node - Indice de compatibilité Angular.

Remarque

Tous les numéros de version de ce document sont spécifiques à la mise à niveau de Windows Admin Center d’Angular 7 vers Angular 11.

En suivant le processus ci-dessus, vous perdrez tous les paramètres globaux du nœud, y compris votre authentification VSTS.

Pour restaurer l’authentification VSTS, exécutez cette commande à la racine de n’importe quel référentiel : vsts-npm-auth -config .npmrc

Autres considérations lors de la mise à niveau des extensions vers Angular 11

  • Le chargement latéral de la coque et des extensions ne doit pas être affecté lorsque vous travaillez avec deux branches de la coque.
  • Lorsque vous utilisez copyTarget, sachez dans quelle branche de l’interpréteur vous vous trouvez. N’utilisez cette commande dans la branche 2.0 que si l’extension avec laquelle vous travaillez est également mise à niveau vers Angular 11.
  • Si le dépôt a été mis à niveau vers Angular 11, utilisez la dernière version 2.x.0 des bibliothèques shell. Sinon, continuez à utiliser la dernière version 1.x.0.

Vous pouvez savoir si un dépôt est mis à niveau en examinant le fichier package.json.