Archives par étiquette : .net 3.5

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 !