Dynamically Adapting To Application Sizes (DATAS), voici un nom auquel il va falloir s’adapter. IL s’agit d’une nouvelle fonctionnalité du GC introduite avec .net 8.

Vous trouverez ici un très bel article décrivant le fonctionnement de DATAS, et quelques indicateurs sur le gain de performances obtenu (merci à Laurent de me l’avoir fait connaitre).

Dans les faits, il faudra attendre la RTM de .net 8 pour se faire une idée de l’implémentation définitive. Sur le principe, cette fonctionnalité va permettre une gestion dynamique du nombre de heaps (augmentation, et diminution). L’augmentation devrait permettre d’accélérer les allocations. La diminution devrait permettre de réduire la consommation globale de l’application.

Depuis que j’ai entendu parler de DATAS, je suis emballé. J’ai cependant un petit regret. La configuration est minimale. Un simple switch on / off. J’aurais aimé disposer d’un contrôle sur les nombres min / max de heap, ou une option pour anticiper les besoins en mémoire.

Ne vous méprenez pas, DATAS est une très bonne chose. Il me semble cependant que cette fonctionnalité devait initialement aller un peu plus loin. Un peu de contrôle n’aurait pas été désagréable ;)

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.