LINQ perd la mémoire

Il existe un cas d’usage où le comportement de LINQ to Entities n’est pas naturel et peut entraîner des erreurs peu faciles à détecter. La seule chose qu’on observe est que certaines conditions ne sont pas prises en compte, seule la dernière étant prise en considération.

Je vais notamment détailler le cas où l’on construit une requête LINQ (donc un SELECT en base de données) dynamiquement et surtout itérativement, c’est à dire où la requête LINQ doit être construite en utilisant une boucle. Ce genre de requête peut être très fréquente lorsqu’on réalise une recherche, ou un moteur de recherche assez souple ou à spectre large par exemple.

Voici en exemple le comportement bizazrre relatif à LINQ ; prenons le code suivant:

En principe, on s’attend à ce que ce code soit identique à :

Or si l’on exécute les extraits de code, on observe que dans le premier extrait query renvoie un ensemble contenant 1, 2 et 3, alors qu’avec le second extrait, query renvoie un ensemble ne contenant que 1.
En réalité, le premier extrait de code est équivalent à ceci :

Mais que s’est-t-il passé ?! On observe que lors de la construction d’une requête LINQ to Entities dans une boucle, la variable de boucle est considérée comme identique. C’est-à-dire que dans mon exemple, LINQ considère que el  est le même à chaque itération, ou plus exactement LINQ ajoute la condition telle quelle textuellement, et en associant à el  une valeur qui est la dernière valeur connue de el .
A la fin de la dernière itération, la requête LINQ contient donc 3 fois la même condition, ( q <= el ), et y a associé pour el , sa dernière valeur, soit 3.

Ce comportement est logique lorsqu’on sait comment LINQ fonctionne en interne, mais paraît particulièrement anti-naturel la première fois qu’on rencontre ce comportement.

L’astuce pour contourner ce défaut (présent au moins dans la version 4 du .NET Framework), consiste à stocker el  dans une variable à portée locale, donc à définir une variable alpha  dans la boucle foreach  et à y affecter el . Dans ce cas, il n’y aura aucune ambiguïté sur la variable et chaque alpha  sera différent dans la requête.

Explication

Lorsqu’on construit la requête à coup d’appel successif à Where , la requête n’est pas exécutée et rien n’est évaluée, elle est construite tout comme on ferait une concaténation de chaîne.
A chaque itération, un appel à Where  génère l’expression q => q <= el (même si fonctionnellement on confond parfois les notions, cette lambda expression n’est pas un délégué ou une méthode, c’est une expression, un objet qui peut être parsé, au même titre qu’une formule mathématique peut être lu pour être interprété), où q  est une variable complètement définit puisque paramètre de l’expression, en revanche la question se pose pour el . Il faut considérer la variable comme une référence (au sens C++) vers la valeur, étant donné que el  est la variable de boucle, à chaque itération sa valeur change mais sa référence reste la même (c’est à dire que la la boite contenant la valeur ne change pas, mais la valeur dans la boite change à chaque tour de boucle).

A l’inverse, lorsqu’on déclare une variable alpha  à l’intérieur de la boucle, on s’assure que la référence de alpha  entre deux itérations est différente (puisqu’on la redéclare à chaque fois).

D’une itération à une autre, on peut alors se demander pourquoi lorsqu’on redéclare alpha , le runtime n’utilise jamais une référence précédemment affecté ? En effet on peut se dire que lorsqu’on passe à l’itération suivante, le alpha  d’avant n’est plus utilisé. C’est faux, les alpha  des itérations précédentes sont utilisés : la requête query  détient une référence vers chaque valeur prises par alpha . Du point de vue du runtime, les blocs mémoires sont donc non libre et le runtime affecte donc un autre bloc mémoire pour alpha  à chaque nouvelle itération.

Voir aussi

Personnaliser le WebDeploy

WebDeploy est un outil dans Visual Studio permettant de compiler puis déployer un projet web sur un serveur IIS. Il est très simple d’usage mais… la personnalisation est inexistante.

Compte tenu de la complexité du processus de build des projets .NET et de la qualité de la documentation fournit, ça n’a pas été évident mais j’ai pu finalement cracher ce bout de XML. Il est à ajouter dans le fichier csproj du projet web à la fin.

Voici ce qu’il fait :

  1. On renseigne en paramètre l’exécutable signtool, qui permet de signer numériquement un fichier PE (ça correspond à l’onglet « Signatures numériques » dans les propriétés d’un fichier signé
  2. On renseigne le certificat à utiliser par sa somme de contrôle SHA1
  3. On indique avec un nom de variable particulier le fichier snk contenant les clés pour ajouter un nom fort aux assemblies. Les variables sont KeyOriginatorFile  et _FullKeyFile  et sont reconnus par le processus de compilation.
  4. Après la compilation normale du projet, on signe le fichier *.dll  et les fichiers *.ressources.dll généré par le projet web
  5. Après l’étape 4, on lance la cible MvcBuildViews qui va compiler toutes les vues dans une assembly qui se nomme {nom du projet web}.WebUI.dll. Une fois que c’est fait, on signe également la nouvelle assembly et ses ressources.
  6. Le processus normal reprend et pousser le résultat sur le serveur IIS

Toutes ces étapes ne sont évidemment pas obligatoires et ce fichier DOIT être personnalisé en fonction de son environnement.

Conserver la position du défilement de la page

Depuis ASP.NET 2, il existe une directive bien sympathique qui permet de repositionner la barre de défilement d’une page après un postback.
Il suffit simplement de positionner la directive MaintainScrollPositionOnPostBack  à true  dans la balise de la page :

C’est quand même mieux que de se farcir un script javascript, non ?

Voir aussi