Voici une nouvelle plaisanterie d’Azure DevOps (il est très taquin aujourd'hui). Lors d’une build Azure Pipeline, le log fait remonter une erreur étrange : Un projet .net framework 4.8 n’aurait pas le droit de référencer un package nuget .net standard 2.

Bien évidemment, si l’on regarde la documentation, ceci est faux. Pourquoi Azure Pipeline se tromperait-il sur un sujet aussi simple ?

La raison ne se cache pas du côté, Azure DevOps. Le problème est lié à l’outillage installé sur le serveur de build. Celui-ci n’utilise pas forcément une version de nuget compatible avec .net standard. La solution la plus simple consiste donc à ajouter une tâche NuGetToolInstaller@1. Celle-ci se chargera d’installer la dernière version de nuget, ce qui résout le problème, et évitera les suivants ;).

Ce qui donne :

steps:
  - task: NuGetToolInstaller@1      
  - task: NuGetCommand@2
    displayName: 'NuGet restore'
    inputs:
      restoreSolution: $(solution)
      command: restore
          
  - task: DotNetCoreCLI@2
    displayName: 'Compilation'
    inputs:
      command: build
      projects: '$(solution)'
      arguments: '--configuration $(buildConfiguration)'

Voici une situation des plus cocasses. Des projets utilisent des packages nuget hébergés dans Azure DevOps. Lors de la build, Azure Pipeline indique qu’il est incapable de charger l’index nuget d'Azure Artefacts.

Au premier abord, on peut penser à un problème de droits d’accès. Mais il n’en est rien. Ou du moins le problème est un peu plus tordu que cela. Les pipelines ont bien le droit d’accéder à repository Azure Artefacts.

Le problème se trouve en fait au niveau de la tâche qui cherche à restaurer les packages. Comme beaucoup, j’utilisais DotNetCoreCLI@2. En temps normal, pas de problèmes. La tâche restaure les packages, et compile les projets. Mais, j’avais beau lui indiquer explicitement la configuration nuget, ou l’URL du repository, rien n’y faisait.

Et puis j’ai eu l’idée un peu folle de faire à l’ancienne. Comme pour les vieilles solutions .net Framework. Pour ceux qui n’ont pas connu cette douce époque. La tâche VSBuild@1 doit être précédée d’une tâche NuGetCommand@2 avec l'option restore.

Si on applique le même principe, on s’aperçoit vite que NuGetCommand@2 accède aux packages et à l’index d’Azure Artefacts. La restauration et la build deviennent donc possibles.

Ce qui donne :

steps:
  - task: NuGetToolInstaller@1      
  - task: NuGetCommand@2
    displayName: 'NuGet restore'
    inputs:
      restoreSolution: $(solution)
      command: restore
      feedsToUse: config
      nugetConfigPath: '$(system.defaultworkingdirectory)/Sources/nuget.config'
          
  - task: DotNetCoreCLI@2
    displayName: 'Compilation'
    inputs:
      command: build
      projects: $(solution)
      arguments: '--configuration $(buildConfiguration)'

Note : La tâche NuGetCommand@2 suffit à avoir une solution fonctionnelle. Cependant, j’ajoute une tâche NuGetToolInstaller@1 afin d’éviter d’autres problèmes. Ceux-ci feront l’objet d’un second article.

Hello amis développeurs !

Via cet article, j’inaugure un nouveau format "court" (en tout cas, je vais tenter de faire court). L’idée est d’apporter une réponse concise, mais suffisante, à des questions que l’on me pose régulièrement en off afin d’avoir une réponse sans tabou.

Commençons simple, avec un sujet qui peut crisper certains développeurs : Faut-il passer à .net 8 tout de suite ou attendre ?

Sans hésitation : Oui.

Deux raisons à cette réponse :

• Il ne faut plus avoir peur d’avoir à essuyer les plâtres quand une nouvelle version de .net sort. Chaque nouvelle version de .net sort avec un niveau de qualité irréprochable. Les nombreuses previews, et le suivi via GitHub y sont pour beaucoup.
• Chaque version paire de .net est une version disposant d’un support à long terme (LTS : pour Long Term Support). Elle est donc supportée par Microsoft pour 3 ans. Ce qui signifie que .net 6 arrivera en fin de support d’ici un an. En migrant tout de suite, on s’assure une certaine tranquillité d’esprit (tant pour les mises à jour de sécurité, le support des OS, et de Visual Studio).

En novembre prochain, il faudra donc dire "Oui" à .net 8, et sauter le pas sans hésitation.

Sur les dernières versions de Windows Server, le changement de fuseau horaire peut poser problème. Ceci peut être causé par une UX devenue un peu pénible, ou par l’usage de Windows Core.

Heureusement, il existe une commande PowerShell pour cela.

Exemple :

Set-TimeZone -Id "Romance Standard Time"

Je n’ai pas utilisé un Id par hazard, j’ai utilisé la commande Get-TimeZone sur un PC se trouvant sur fuseau horaire qui m’intéressait.

Exemple de message retourné par Get-TimeZone :

Id                         : Romance Standard Time
HasIanaId                  : False
DisplayName                : (UTC+01:00) Bruxelles, Copenhague, Madrid, Paris
StandardName               : Paris, Madrid
DaylightName               : Paris, Madrid (heure d’été)
BaseUtcOffset              : 01:00:00
SupportsDaylightSavingTime : True

Simple, rapide, et utilisable sur toutes les versions actuelles de Windows, et Windows Server.

Généralement, quand je parle de créer un programme d’installation, je vois les développeurs se déliter. Il s’agit le plus souvent d’un problème de méconnaissance du sujet. Si par chance un développeur a déjà travaillé sur ce genre de projet, la conversation tourne très rapidement autour des outils, de leur coût, et de leur complexité d’usage.

L'objectif

Aujourd’hui je souhaiterais donc clarifier ce qui se cache derrière cette fameuse « complexité ». Soyons honnêtes tout de suite, cet article ne finira pas en disant que les choses sont toujours simples. Un scénario d’installation complexe fera certainement appel à des solutions avancées, et potentiellement complexes.

Je m’appète simplement à présenter le sujet qui rend ce genre de projet peu évident : la génération de fichiers MSI.

Même si votre installation utilise un exécutable pour bootstrapper votre déploiement (installer un ensemble de programmes, ou valider des prérequis), il y aura toujours un ou plusieurs MSI derrière.

Petite parenthèse sur le MSIX :

Certains diront peut-être qu’aujourd’hui il y a le MSIX, et qu’il résout tout. Oui, le MSIX est très intéressant. Mais en installez-vous tous les jours dans votre vie personnelle ? Vous avez déjà tenté de voir si vos serveurs supportaient ce format ? Votre infrastructure ? Vos utilisateurs ?

Désolé pour encore quelques années, le MSI sera la norme. Il faut vivre avec, et prendre le temps de savourer ses avantages.