Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

Voici la remédiation à un problème que j'ai récemment constaté sur un serveur hébergeant Azure DevOps.

Le disque système n'avait plus le poindre espace libre.

Après un petit diagnostique, j'ai constaté que le dossier "C:\inetpub\logs\LogFiles" contenait de gigaoctets de logs. S'agissant d'un dossier de IIS, la solution consistait donc, à reconfigurer lIS afin qu'il gère différemment ses logs.

Cela se fait en ouvrant la console IIS, en sélectionnant le site Azure DevOps, puis "Journalisation". Ici, il est possible de modifier la manière dont IIS gère les logs (planifications, tailles de fichiers, etc. ). Personnellement, je déteste explorer les logs pour identifier un problème, je préfère utiliser l'observateur d'évènements.

J'ai donc choisi de désactiver les logs au format fichier.

Ce qui donne la configuration suivante :

Depuis TFS 2008, c'est bien la première fois que je vois IIS configuré de la sorte. Je présume qu'il s'agit donc d'un cas isolé. Mais au cas où je préférais partager la remédiation ici.

Si vous utilisez Duende.IdentityModel.OidcClient, ou toute autre librairie .net permettant de s'authentifier avec Entra Id, vous souhaitez peut-être utiliser son SSO. Par chance, la solution ne se cache pas dans une librairie tierce, mais dans le rutime WebView2 lui-même.

Ceci passe par l'utilisation d'une option lors de l'initialisation du runtime de WebView2. il s'agit de l'option AllowSingleSignOnUsingOSPrimaryAccount. Celle-ci peut s'utiliser de la manière suivante :

var options = new CoreWebView2EnvironmentOptions() {
  AllowSingleSignOnUsingOSPrimaryAccount = true
};

var environment = await CoreWebView2Environment.CreateAsync(options: options);
await _browser.EnsureCoreWebView2Async(environment);

Voici un warning rencontré lors de l'utilisation d'un flux nuget privé :

Error occurred while getting package vulnerability data: Unable to load the service index for source http://.../tfs/.../_packaging/.../nuget/v3/index.json.

Je l'ai constaté avec Azure DevOps Server, mais il peut être observé avec d'autres fournisseurs n'hébergeant pas d'index des vulnérabilités.

Heureusement, le client nuget peut être configuré pour utiliser une liste de sources propre aux audits de sécurité. Cette configuration est extrêmement simple. Exemple : pour n'utiliser que nuget.org :

<configuration>
    <auditSources>
        <clear />
        <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    </auditSources>
</configuration>

Ceci est documenté ici : Auditing package dependencies for security vulnerabilities | Microsoft Learn

Histoire de rester fidèle à mes mauvaises habitudes, je vais commencer cet article par la fin : non, je ne suis pas partisan du vibe coding. Cette méthode ne me semble pas destinée aux développeurs. Le simple fait que l’on ne s’intéresse au code, ne serait-ce que pour valider sa qualité, ou sa maintenabilité me répugne. Mais je suis développeur dans l’âme. Je suis donc friand de nouvelles solutions, et j’observe.

Note : Je publierai prochainement un article sur un usage du vibe coding qui me semble pertinent, et qui sort totalement du cadre que l’on nous présente habituellement.

Si on demande à Copilot, de parler du vibe coding, on peut obtenir ce résumé.

Vibe coding is an AI-assisted programming approach where users describe their software needs in simple language, and AI, particularly large language models (LLMs), generates the corresponding code. This technique allows individuals with little to no coding experience to create software by simply "following the vibes" of what they want, without needing to understand the underlying code. While it speeds up development, there are concerns regarding code quality, security, and maintainability. The term was coined by AI researcher Andrej Karpathy.

Le vibe coding, est là. Il faut vivre avec.

Bien avant le vibe coding

J’ai la chance de faire partie de ces développeurs qui ont débuté leur passion avant la généralisation d’Internet. Une époque merveilleuse, où chaque développeur prenait le temps d’installer la version la documentation fournie avec Visual Studio. Il fallait alors avoir le courage d’enchaîner les CD …

Une MSDN “hors ligne” qui prenait une place folle sur les PC. Cela devrait rappeler des souvenirs aux plus anciens.

À l’époque, il n’était pas facile d’échanger avec d’autres développeurs plus expérimentés. Il fallait donc prendre le temps de maitriser cette documentation afin d’en extraire les fragments de code salvateurs.

Un peu avant le vibe coding

Avec la généralisation d’Internet, la documentation est devenue plus accessible. Les sites de partages de code, et forums se sont multipliés (mon petit favori : VB France).

Même s’il est devenu plus facile d’échanger avec ses pairs, nombre de développeurs se sont alors mis à copier des bous de code, sans trop comprendre ce qu’ils faisaient.

Qui n’a jamais trouvé dans son application un pan entier de code tiré de Stack Overflow ? Ou un code rédigé par un collègue comportant des commentaires en anglais alors que celui-ci y est allergique ?

Aujourd’hui

Le vibe coding, est là avec ses nouveaux outils, et ses nouvelles pratiques. Même si je ne peux pas adhérer à l’idée d’utiliser un code que je ne prendrais pas le temps de comprendre, je pense qu’il faut rester ouvert.

Le vibe coding n’en est qu’à ses débuts. Son avenir en l’état me semble tout aussi incertain que celui des applications jetables que l’on pourrait générer avec. Je vois déjà les vagues de commerciaux d’ESN qui pense pouvoir vendre des prestations réalisées va le vibe coding, et qui dans quelques mois vont avoir du mal, à trouver des développeurs expérimentés pour faire la maintenance.

Conclusion

Gardons à l’esprit que personne n’a vraiment encore un grand recul sur cette approche.

Il s’agit d’une évolution du métier qu’il faut prendre en compte. Il y a des chances que de bonnes choses en ressortent… Même si je ne vois pas encore quoi.

Depuis .net 9, Microsoft permet de profiter simplement OpenAPI. Si de base je ne trouve pas OpenAPI extraordinaire (car en 2025, tout le monde ne semble toujours pas en accord avec ce standard), je dois avouer que j'apprécie beaucoup l'implémentation fournie par Microosft. Principalement pour sa légèreté, et sa gestion des metadata (Include OpenAPI metadata in an ASP.NET Core app | Microsoft Learn).

Si votre projet utilise encore Swagger, il est possible de passer très rapidement à OpenAPI. L'opération est simple et rapide.

Dans un premier temps, il suffit de remplacer la dépendance Swashbuckle.AspNetCore :

<PackageReference Include="Swashbuckle.AspNetCore" Version="8.1.1" />

Par Microsoft.AspNetCore.OpenApi :

<PackageReference Include="Microsoft.AspNetCore.OpenApi" Version="9.0.4" />

Pour finir, il n'y a plus qu'à remplacer ce code :

builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
  app.UseSwagger();
  app.UseSwaggerUI();
}

Par :

builder.Services.AddOpenApi();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
  app.MapOpenApi();
}

Simple, non ?