Archives par étiquette : .net 4.0

image

TextChanged… ou pas (encore)…

C’est dès la première semaine où je suis arrivé chez mon nouvel employeur que j’ai
pu m’exclamer en indiquant que “Rah purée, c’est pas vrai, c’est un bug de WPF…”

Je n’ai pas vu de sourire moqueur de mes collègues mais je suis à peu près sûr que
certains d’entre eux ont dû se dire qu’il était osé de rejeter la faute du bug que
j’avais introduit sur la technologie elle-même et non pas sur une erreur d’inattention.
Et quelques recherches plus tard, je me suis rendu compte… que j’avais bien raison
!

Le scénario est pourtant très simple, il s’agit tout simplement de modifier le texte
d’une TextBox. La particularité de cette modification est que je l’ai réalisé dans
l’évènement TextChanged comme ceci :

image

Je m’attendais à voir le message “Je suis vide” après un click sur mon bouton et bien…
non, ma textbox auparavant remplie devient vide. Et pourtant je rentre bien dans ma
condition et si je mets un espion sur la valeur de la propriété Text elle est bien
définie avec ma chaine. Seul l’affichage n’est pas impacté. Bizarre non ?

Et bien je me suis conforté dans l’idée qu’il s’agissait d’un bug, lorsque je n’ai
pas réussi à reproduire le soucis dans une application .net 4.0. En effet si l’on
fait le test dans VS 2010 et que l’on change de version de framework on se retrouve
avec l’effet désiré ou non !

[Update] Je vous propose ci-dessous le projet de test afin que vous puissiez changer
la version du framework et voir le changement de comportement :

<br />

image

Integrated Security = True ou SSPI ?

Est un exemple de question à laquelle je connais la (bonne) réponse, sans trop savoir
pourquoi. J’ai donc profité que l’on me pose de nouveau la question pour effectuer
quelques recherches.

Afin de mettre en place l’authentification Windows pour une connexion vers SQL Server
il existe donc deux possibilités : utiliser Integrated Security = true ou Integrated
Security = SSPI.

A la question, lequel est le mieux, j’ai répondu SSPI sans trop savoir la vraie raison.
Ce à quoi un collègue m’a répondu en me demandant pourquoi le Server Explorer de Visual
Studio générer une chaine de connexion avec “True” si “SSPI
était meilleur.

Donc la réponse définitive est simple : Il vaut mieux utiliser SSPI
la place de True et ceci pour deux raisons :

Donc pourquoi Visual Studio génère le contraire ?

Parce ce que par défaut il utilise le provider SQL Client de .net : image

Il doit donc probablement faire appel à ce provider pour générer la chaine de connexion
qui va donc générer le true. Si l’on sélectionne celui d’OLE DB, on retrouve bien
le SSPI. Et ce provider ne doit probablement pas respecter la recommandation, et probablement
à tort !

Quand la CLR V2, la CLR V4 et du code mixte se rencontrent

“Mixed mode assembly is built against version ‘v2.0.50727’ of the runtime and
cannot be loaded in the 4.0 runtime without additional configuration information”

Voici le petit message d’amour que peut vous renvoyez votre ami la CLR lorsque vous
essayez d’exécuter une application qui :

  • référence une assembly mixte (mêlant code natif et code managé) qui a été compilée
    pour être basée sur une version différente de la CLR utilisée par votre point d’entrée.

La solution à ce problème est assez simple, il suffit de rajouter une section dans
votre fichier de config :

<configuration>

<startup useLegacyV2RuntimeActivationPolicy="true">

<supportedRuntime version="v4.0"/>

</startup>

</configuration>

L’attribut useLegacyV2RuntimeActivationPolicy

La clé du problème se situe donc dans l’utilisation de l’attribut useLegacyV2RuntimeActivationPolicy
qui est à false par défaut. Cet attribut permet de changer la politique de chargement
de CLR au sein de votre application. Il y a eu en effet un gros changement à ce sujet
:

  • Dans l’ère pré-CLR V4, en V2 quoi, il n’était possible de charger
    qu’une seule version de CLR au sein d’un process. La politique par défaut était de
    charger toutes vos assemblies en utilisant la version la plus récente de la CLR que
    vous aviez à disposition. Cette stratégie a comme avantage que votre ancien code bénéficie
    automatiquement des améliorations apportées par des versions plus récentes de CLR.
    Mais cela pouvait posait des problèmes de compatibilité dans certains rares cas.
  • Avec la CLR V4, il est à présent de charger différentes versions
    de CLR au sein d’un même process et afin de ne plus être confronté aux problèmes de
    compatibilité la politique de chargement a changé. A présent les assemblies basées
    sur la CLR 4, utilisent la CLR 4, et les autres utilisent la version la plus récente
    inférieure à la V4.

Le problème avec les assemblies mixtes c’est que la CLR doit être capable de savoir
quelle est la CLR a utiliser lorsque un thread natif appel du code managé. Il faut
donc désactiver le side by side afin d’avoir une seule version identifiable.

Mais pourquoi ça marche très bien depuis mes tests unitaires ?

Confronté au problème une de mes premières questions a été de comprendre pourquoi
mon code fonctionne très bien depuis mes tests unitaires alors qu’il plante lorsque
je l’appelle depuis mon application. Le moteur d’exécution des tests unitaires MSTest
est QTAgent.exe (QTAgent32.exe en version 32 bits, et oui VS 2010 supporte enfin l’exécution
de tests unitaires en 32 et 64 bits). Si l’on va farfouiller
un petit peu dans le dossier C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDE
à la recherche des fichiers de configs des tests runners on se rend compte que Microsoft
a configuré le chargement de runtime via le fameux attribut useLegacyV2RuntimeActivationPolicy.

Ce qui veut donc dire que par défaut tous vos tests unitaires utiliseront uniquement
la V4 de la CLR et que le hosting de CLR Side by Side est désactivé pour tous vos
tests unitaires.

 

image

PostItCast #1 : Hosting de CLR Side by Side dans un même process (In Proc SxS)

Comme annoncé hier, je
vous propose un webcast décrivant l’hébergement de différentes versions de CLR au
sein d’un même process grâce au framework .net 4 et la CLR 4. Le programme est simple
: Aucun slide, 1 PostIt édité tout au long de la vidéo, et des démos.

Synthèse de la vidéo :

image

Vidéo :

 

Vous pouvez également le télécharger ici  :

N’hésitez pas à me faire vos retours sur ce webcast via les commentaires !

En savoir plus :

http://channel9.msdn.com/shows/Going+Deep/CLR-4-Side-by-Side-In-Process-What-How-Why/

http://blogs.msdn.com/clrteam/archive/2009/06/03/in-process-side-by-side-part1.aspx

http://blogs.msdn.com/clrteam/archive/2009/06/07/in-process-side-by-side-part-2-common-in-proc-sxs-scenarios.aspx