Nerdctl introuvable sur Windows?

Si vous avez installé Rancher Desktop sur un PC et que vous n’arrivez pas à lancer nerdctl, ne paniquez pas. Il y a une solution simple.

Il suffit d’ajouter le dossier bin de Rancher Desktop à sa variable d’environnement PATH. Ce dossier se trouve dans un répertoire AppData du profile utilisateur. Cela complique un peu la chose, mais sans plus.

Avec PowerShell, cela peut se faire de la manière suivante :


$Path = "$Env:Path;$Env:UserProfile\AppData\Local\Programs\Rancher Desktop\resources\resources\win32\bin"
[Environment]::SetEnvironmentVariable('PATH', $Path, 'User')
Jérémy Jeanson

Utiliser AutoFixture.Xunit2 avec des classes internes

Si vous utilisez AutoFixture.Xunit2 avec xUnit pour instancier des classes internes, vous êtes certainement tombé sur un message d’erreur lors de la compilation indiquant que la classe testée était moins accessible que la méthode de tests.

Exemple :

[Theory]
[InlineAutoData]
public void DoSomething_False(ClassATester obj)
{
  var actual = obj.DoSomething();
  actual.Should().BeFalse();
}

Ceci est tout à fait normal.

La solution pour résoudre le problème va peut-être vous sembler déconcertante. Il suffit en fait de rendre la méthode interne.

Exemple corrigé :

[Theory]
[InlineAutoData]
internal void DoSomething_False(ClassATester obj)
{
  var actual = obj.DoSomething();
  actual.Should().BeFalse();
}

Le test sera exécuté, car le runtime de xnit recherche les méthodes décorées avec les attributs Fact et Theory. Le fait que la méthode de test soit interne ne pose donc pas de problème ;).

Jérémy Jeanson

Rendre visibles les classes et méthodes internes facilement

Avec les nouveaux fichiers projets de .net il est très facile de rendre visibles des éléments internes d’un projet (pour les tests par exemple).

Il suffit d’ajouter le nœud InternalsVisibleTo à son projet, et de renseigner son attribut Include avec le nom de l’assembly qui doit voir les éléments internes.

Exemple pour un projet .net 6 :

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
	<InternalsVisibleTo Include="$(AssemblyName).Tests"/>
  </ItemGroup>
	
</Project>

Dans cet exemple, le projet de tests porte le même nom que mon projet + le suffixe ".Tests".

Il n’est donc plus utile d’ajouter l’attribut InternalsVisibleToAttribute à une classe du projet.

Jérémy Jeanson

Attention à ne pas trop faire confiance au geo-blocking

Régulièrement, j’entends ou je lis des personnes se réjouissant du niveau de sécurité offert par le geo-blokcing. Cette fonctionnalité offerte par certains firewalls permet d’interdire l’accès à une application ou un port à partir d’une certaine zone géographique.

L’idée est de se prémunir d’attaques provenant de pays connus pour abriter de nombreux pirates. Sur le papier, cette idée est séduisante, tant que vous n’avez pas à fournir de service dans ces mêmes zones ;).

Dans les faits, je le geo-blocking est loin d’être une nouveauté. Nombre d’attaquants se sont organisés pour le contourner. Par exemple, voici une partie du reporting CloudFlare concernant ce blog :

40 FIREWALL MITIGATED EVENTS

TOP 3 COUNTRIES :

  • France: 24
  • India: 7
  • United States: 4

Note : ce n’est pas le premier mois durant lequel j’ai la France et les USA dans le top 3.

Conclusion

Il ne faut donc pas se croire totalement à l’abri après avoir mis en place le geo-blocking. Il s’agit d’un outil efficace qui ne peut se suffire à lui-même.

Jérémy Jeanson

Fin du support du Data Warehouse et d’Analysis Service dans Azure DevOps Server 2022

C’est officiel depuis lundi dernier, Azure DevOps Server 2022 ne supportera plus SQL Server Reporting Services pour fournir des rapports.

The Warehouse and Analysis Service was deprecated in the previous version of Azure DevOps Server (2020). In Azure DevOps Server 2022 the Warehouse and Analysis Service has been removed from the product. Analytics now provides the in-product reporting experience.

Source : Azure DevOps Server 2022 – RC1 Release Notes

Analytics devient donc l’unique solution d’analyse / reporting :

  • Sur le site Azure DevOps Server, via ses widgets.
  • Hors du site Azure DevOps Server, via ses flux OData.

Pour l’automatiser de rapports, il faudra donc passer par Power BI, et utiliser les flux OData d’Azure DevOps Server.

Ce changement va simplifier les déploiements et la maintenance ;)

Jérémy Jeanson