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

En 2024, les développeurs .net commencent à être habitués aux acronymes STS/LTS associés aux différentes versions de .net. Mais tous ne saisissent pas forcément les implications de ceux-ci. Le plus souvent la réponse apportée peu se résume dans le tableau suivant :

Alors, oui certaines personnes peuvent confondre le premier S de STS avec Short, mais la vraie méprise n'est pas là.

Le statut "Maintenance support", cela vous parle ?

Il s'agit de la situation dans laquelle se trouve toute version de .net quand elle arrive dans ses 6 derniers mois de support. Durant cette période, vous ne recevrez que des correctifs de sécurités. Cela signifie que si un bug venait à être découvert durant cette période, il ne serait pas corrigé. Il vous serait juste recommandé de passer à une version supérieure.

Tout cela est expliqué sur la page ".NET and .NET Core Support Policy".

Maintenant, vous voyez peut-être où je souhaite en venir. La version 7 de .net arrive en fin de vie le 14 mai 2024, cela signifie que :

• .net 7 est déjà limité à un support de type maintenance depuis novembre 2023.
• .net 6 sera limité à un support de type maintenance en mai 2024.
• .net 8 sera la seule version avec un support actif passé mai 2024.

Moralité

La fin de support de .net 7 est un jalon très important. Il est fortement recommandé de passer à .net 8 avant cette date. Voilà pourquoi les développeurs .net doivent migrer leurs applications dans les 6 mois qui suivent la publication d'une nouvelle version LTS. Considérer que vous avez davantage de temps pour le faire est une erreur. Que vous utilisiez une version LTS ou STS.

Voici une situation peu ragoutante que j'ai rencontrée il y a déjà quelque temps. IIS ne permettait pas la suppression d'un pool.

Heureusement, tout IIS est pilotable via PowerShell. Il suffit de connaitre les bonnes commandes.

L'application bloquant la suppression du pool n'était pas visible via la console. Dans un tel cas, il faut donc commencer par identifier les sites, et les applications que IIS ne semble pas vouloir afficher. Pour cela, il y a deux commandes à connaitre :

Get-Website
Get-WebApplication

Pour l'exemple, imaginons que je trouve une application app1 qui se trouvait dans le site web site1. Pour pouvoir supprimer cette application, il faut donc utiliser la commande :

Remove-WebApplication -Name app1 -Site site1 

Pour finir, le pool nommé pool1 dans mon exemple peut être supprimé via cette commande :

Remove-WebAppPool –Name pool1

L'une des choses que je préfère avec Blazor, consiste dans la possibilité de tester intégralement un composant via bUnit. Un bon exemple valant toujours mieux que de long discourt, voici un cas simple permettant de résoudre deux problématiques :

• Le besoin de modifier un input.
• Le besoin de consulter le contenu d'un input.

Pour commencer, on peut initialiser un contexte de test, et effectuer un rendu d'un composant :

// Création du context de test 
using var context = new TestContext();

// Création du composent et rendu
var obj = context.RenderComponent<MonComposent>();

Pour modifier une input dont l'Id serait inputId, on peut utiliser le code :

obj.Find("#inputId").Change("Ma valeur");

Pour consulter le contenu d'un input dont l'ID serait inputId, on peut utiliser le code :

var actual  = obj.Find("#inputId").GetAttribute("value");

Pour finir, voici un exemple complet :

[Theory] 
[InlineData("Foo")] 
public void Exemple(String value) 
{
  // Création du context de test 
  using var context = new TestContext(); 

  // Création du composent et rendu 
  var obj = context.RenderComponent<MonComposent>(); 

  // Modification
  obj.Find("#inputId").Change(value); 

  // … ajouter des interactions avec le composant ici 

  // Vérifier la valeur de l'input 
  var actual= obj.Find("#inputId").GetAttribute("value"); 
  actual.Should().BeEquivalentTo(value);  
} 

Conclusion

Voici du code simple et efficace. Tout ce que j'aime!

Dans un précédent article, je présentais la démarche à suivre pour exécuter une action custom avec des privilèges élevés. Cette approche passe par l'exécution de l'action dans un contexte deferred. Celui-ci a un impact sur la manière d'accéder aux propriétés via l'action custom.

Habituellement, WiX toolset permet d'utiliser la syntaxe qui suit pour accéder à des paramètres lors de l'installation. Dans le cadre d'une action custom deferred, le code suivant n'est pas utilisable.

[CustomAction] 
public static ActionResult DoSomething(Session session) 
{ 
  var destination = session["INSTALLFOLDER"]; 
  // … 
}

Il doit être remplacé par :

[CustomAction] 
public static ActionResult DoSomething(Session session) 
{ 
  var destination = session.CustomActionData["INSTALLFOLDER"]; 
  // … 
}

CustomActionData est alimenté via la propriété Value de l'action custom. Le contenu accepte une syntaxe du style nom1=valuer1;nom2=valeur2;....

Malheureusement, cette propriété ne peut pas être affectée directement. Il faut ajout une seconde action custom pour cela. Dans l'exemple suivant, j'ai créé une action custom SetDoSomethingValue qui affecter les propriétés que j'utilise dans l'action custom DoSomething.

<!-- Actions personnalisées --> 
<Binary Id="CustomActions" 
    SourceFile="CustomActions.CA.dll"/> 

<CustomAction Id="DoSomething" 
    BinaryRef="CustomActions" 
    DllEntry="DoSomething" 
    Execute="deferred" 
    Return="check" 
    Impersonate="no"/> 

<CustomAction Id="SetDoSomethingValue" 
    Property="DoSomething" 
    Value="INSTALLFOLDER=[INSTALLFOLDER]"/>

Ben évidemment, l'action custom SetDoSomethingValue doit être ajoutée à la section InstallExecuteSequence, et s'exécuter avant l'action DoSomething.

<InstallExecuteSequence>
  <Custom Action="DoSomething" Before="InstallFinalize" Condition="NOT REMOVE"/> 
  <Custom Action="SetDoSomethingValue" Before="DoSomething" Condition="NOT REMOVE"/> 
</InstallExecuteSequence>

Par défaut, lors du déploiement, une action custom s'exécute avec les privilèges de l'utilisateur courant. Celle-ci ne dispose d'aucun privilège administrateur. Le fait de fixer un scope perMachine comme ceci ne suffit pas :

<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs"> 
  <Package 
     Name="..." 
     Scope="perMachine"> 

Une solution peut consister dans le fait de d'utiliser un terminal avec une élévation de privilège pour lancer msiexec (msiexec /i mon-fichier.msi).

Heureusement WiX Toolset, permet de demander à Windows Installer d'exécuter une action custom avec des privilèges élever facilement. Pour cela, il faut utiliser l'option deferred pour la propriété Execute, et no pour la propriété Impersonate. La raison de ce changement est expluqée ici : Immediate Custom Actions Always Impersonate - Visual Studio Setup (microsoft.com)

Exemple :

<!-- Actions personnalisées --> 
<Binary 
    Id="CustomActions" 
    SourceFile="CustomActions.CA.dll"/> 
<CustomAction Id="DoSomething" 
    BinaryRef="CustomActions" 
    DllEntry="DoSomething" 
    Return="check" 
    Execute="deferred" 
    Impersonate="no"/>

Bien évidemment, l'action custom DoSomething doit être présente dans la séquence InstallExecuteSequence. Son exécution doit être planifiée entre InstallExecute, et InstallFinalize.

<InstallExecuteSequence>
  <Custom Action="DoSomething" Before="InstallFinalize" /> 
</InstallExecuteSequence> 

Après avoir appliqué ces modifications, l'action custom s'exécutera toujours avec des privilèges élevés.