VSS : Lister tous les projets (ligne de commande)

VSS… Ca ne me rajeunit pas !
Accéder au répertoire de l’outil « ss.exe » :
cd C:Program FilesMicrosoft Visual StudioVSSwin32
Lancer la commande :
ss Dir $/
 
A noter que les variables d’environnement suivantes doivent être renseignées :
SSUSER : Spécifie le nom d’utilisateur à utiliser pour les opérations de ligne de commande.
SSDIR : Spécifie l’emplacement du fichier Srcsafe.ini (base de données VSS à laquelle se connecter).
 
That’s a bingo !

ColorSeeds pour Windows Phone 7

ColorSeeds pour WP7 disponible depuis novembre 2010.
## UPDATE 18/02/2011
La version 1.1 a été mise à jour en 2.0 (avec le fameux mode « infini »).
Une version debuggée de la 1.1 passe en gratuit sur le Marketplace (version 1.2). En 3 jours de présence, déjà 600 exemplaires téléchargés !
## UPDATE 23/12/2010
Blog officiel du jeu : http://colorseeds.wordpress.com
## UPDATE 19/11/2010
Voici donc « ColorSeeds » disponible sur le MarketPlace Zune !
Je voulais le proposer gratuitement, mais impossible d’insérer une bannière pub pour les développeurs européens !
Le jeu propose une version d’essai de 15 niveaux, puis 0.99€ pour les 56 niveaux 😉
Pourquoi ce changement de nom de ColorVirus à ColorSeeds ? J’avais peur que le terme « Virus » effraie le comité de validation des appli et la ménagère de moins de 50 ans lol
##
 
Me voilà reparti depuis 2 mois sur le portage de ColorVirus pour mobile.
J’avais déjà fait un essai infructeux pour Android (Eclipse + plugins = l’enfer !). Et puis Microsoft se décide à offrir tout un toolkit de développement pour Windows Phone 7 :

  • Visual Studio 2010 Express pour Windows Phone
  •  Emulateur Windows Phone
  •  Silverlight pour Windows Phone
  •  XNA Game Studio 4.0

Une aubaine !
J’espère pouvoir soumettre mon appli sur market place à l’automne, quand les premiers smartphones débarqueront.

.NET : Génération d'une image à la volée

I believe I can (make an image on the) flyyyyyyy !
Imaginons qu’on veuille afficher une image qui changerait d’aspect à chaque chargement de page (graphiques, clavier virtuel pour l’authentification…). Il ne serait pas pratique de stocker ces images temporaires côté serveur (il faudrait être sûr de donner un nom unique aux images pour éviter les conflits par exemple).
La solution qui suit permet d’éviter de stocker des images sur le serveur. On va créer une page ASPX qui retourne un flux de type MIME « image/*** ».
Dans la page qui affichera l’image générée, il faut une balise de la sorte :
<img src="GenerateurImage.aspx" alt="" />
La page GenerateurImage.aspx ne contient rien (ou le minimum).
Tout se passe dans la procédure page_load du code-behind (
GenerateurImage.aspx.cs) :
public void Page_Load(object sender, System.EventArgs e)
{
// On peut partir d'une bitmap existante, ou en générer une nouvelle :

           Bitmap oBit = new Bitmap(???);
Graphics g =
Graphics.FromImage(oBit)


// Ici on modifie l'image avec toutes les méthodes offertes par la classe Graphics.
// On pourrait éventuellement utiliser des paramètres de la requête (ID=...)
pour rendre la chose encore plus dynamique !
// On change le type de flux de sortie
Response.ContentType = « image/jpeg »;
// On encode (compression)
ImageCodecInfo myImageCodecInfo;
Encoder myEncoder;
EncoderParameter myEncoderParameter;
EncoderParameters myEncoderParameters;
myImageCodecInfo = GetEncoderInfo(« image/jpeg »);
myEncoder = Encoder.Quality;
myEncoderParameters = new EncoderParameters(1);
// Niveau d’encodage élévé.
myEncoderParameter = new EncoderParameter(myEncoder, 100L);
myEncoderParameters.Param[0] = myEncoderParameter;
oBit.Save(Response.OutputStream, myImageCodecInfo, myEncoderParameters);
oBit.Dispose();
// Pas de cache pour cette page.
Response.CacheControl = « no-cache »;
Response.AddHeader(« Pragma », « no-cache »);
Response.Expires = -1;
}
En bonus, la fonction qui ramène le codec :
        private static ImageCodecInfo GetEncoderInfo(String mimeType)
{
int j;
ImageCodecInfo[] encoders;
encoders = ImageCodecInfo.GetImageEncoders();
for (j = 0; j < encoders.Length; ++j)
{
if (encoders[j].MimeType == mimeType)
return encoders[j];
}
return ';
}

SharePoint : Bug natif dans le modèle de liste "Forum de discussion"

Un paquet de CAML !
Quelque soient les droits des utilisateurs dans un forum de discussion SharePoint, le lien « Afficher les propriétés » apparait pour chaque message. Or ce lien redirige vers les propriétés du message, où il est possible de le modifier, le supprimer…
Résultat : l’utilisateur va se retrouver devant une page d’erreur quand il tentera ces actions.
Pour corriger ce dysfonctionnement natif, le mieux et de créer son propre modèle de liste DiscussionList (en copiant-collant l’original), et de corriger le fichier %FEATURE%DiscussionsListDiscussschema.xml
Dans notre cas, on va simplement afficher ce lien uniquement aux utilisateurs qui sont l’auteur du message. A la ligne 351du fichier, il faut remplacer le code défécteux par celui-ci (entre le </Switch> de la ligne 351 et le <IfHasRights> de la ligne 354) :
          <HTML><![CDATA[<td style="border-style:none" nowrap="TRUE"><div>]]></HTML>
<IfEqual>
<Expr1>
<Column Name="Author"/>
</Expr1>
<Expr2>
<UserID></UserID>
</Expr2>
<Then>
<HTML><![CDATA[<a id="DisplayLink]]></HTML>
<Field Name="ID" />
<HTML><![CDATA[" href="]]></HTML>
<URL Cmd="EDIT" />
<HTML><![CDATA[" ONCLICK="GoToLink(this);return false;" target="_self">]]></HTML>
<HTML><![CDATA[<NOBR>Afficher les propriétés</NOBR></a>]]></HTML>
</IfHasRights>
</Then>
</IfEqual>


Bien sûr, tout ceci peut être libre de toute fantaisie !

XSL / Sharepoint : "L'affichage spécifié n'est pas valide"

C’est pas du 16/9ème ?
… ou encore en anglais : « The specified view is invalid ».
Cette erreur peut intervir lorqu’on créé une DataFormWebPart (DFWP) sous le SharePoint Designer (en partant d’une webpart native (ListViewWebPart), et en la convertissant en vue XSL).
Lorsqu’on va exporter cette webpart, et l’intégrer dans une page, l’erreur va survenir. Il va alors falloir aller dans la page de maintenance et supprimer la WP.
Certains forums donneront cette solution : Editer le fichier *.webpart dans un bloc-note, et supprimer la propriété « viewflag« . Mais cette action à des effets de bord bien plus perfides.
Je pense (pour l’instant) que la meilleure chose à faire et de partir d’une source de données (au lieu d’une webpart native) pour créer sa DFWP.
 

Expressions régulières : mot de passe complexe

3 heures d’enquête pour ça !
Voici l’expression régulière pour valider un mot de passe constitué ainsi :
– Doit avoir 6 caractères exactement
– Doit contenir 4 chiffres, 1 seule lettre (parmis A, B, C, D et E) et 1 seul caractère spécial (# ou @)
Tout ceci dans n’importe quel ordre.
L’espression régulière est donc la suivante :
^(?=(.*[0-9].*){4})(?=.*[A-E])(?=.*[@#]).{6}$
La difficulté provient de « 1 seule lettre » et « 1 seul spécial ». Ce qui revient à « 4 chiffres exactement ».
« 4 chiffres exactement » se traduit par la « look-back assertion » ou « traitement lookaround » suivant : (?=(.*[0-9].*){4})
 
Tests :

A#1234 : vrai

AB#123 : faux
1A#@12 : faux
1A#312 : vrai
 

XSL / Sharepoint : Doublons des entrées dans les filtres (DataFormWebParts)

La chose faite d’houblon.
Dans le cas de DataFormWebParts à sources de données aggrégées, il se peut que les filtres des en-têtes contiennent plusieurs fois les mêmes valeurs.
Ce petit bug d’affichage est corrigible en allant manipuler le code XSL de la page (via le SharePoint Designer).
Dans le template nommé « dvt.filterfield« , trouver une boucle for-each qui appelle le template « filteroption » :
     <xsl:call-template name="dvt.filteroption">
<xsl:with-param name="name" select="$fieldname" />
<xsl:with-param name="value" select="." />
<xsl:with-param name="type" select="$fieldtype" />
</xsl:call-template>

La boucle qui appelle ce template est censée faire un « distinct » sur les données à lister, mais ça ne fonctionne pas toujours.
Les données sont cependant triées, on va donc autoriser l’affichage de la donnée à chaque fois qu’on change de valeur dans la boucle. Pour cela, il suffit d’encadrer cet appel par la condition suivante :
     <xsl:variable name="OptionValue" select="ddwrt:NameChanged(string(.), 0)" />
<xsl:if test="string-length($OptionValue)">


          <xsl:call-template name="dvt.filteroption">
<xsl:with-param name="name" select="$fieldname" />
<xsl:with-param name="value" select="." />
<xsl:with-param name="type" select="$fieldtype" />
          </xsl:call-template>
     </xsl:if>
 
NB : NameChanged teste si une valeur change depuis sa dernière affectation.

XSL / XPath / Sharepoint : Problème du double encodage des données.

L’esperluette m’a tué
J’ai rencontré ce problème en créant une « DataFormWebPart » sous le Sharepoint Designer. Les données finales affichées (HTML) étaient doublement encodées par rapport à la source de données.
Prenons cet élément d’une liste SharePoint :
L'iPad est nul
A travers une DataFormWebPart créée sous le sharepoint Designer, il ressortira ainsi
L&quot;iPad est nul
 
Cause : il y a eu double encodage : L'iPad est nul -> L&quot;iPad est nul -> L&amp;quot;iPad est nul
Et sur le navigateur, le résultat est celui-ci : L&quot;iPad est nul
 
Le problème vient du XSL, au moment d’afficher la valeur :
<xsl:value-of select="@Valeur"/>
Il faut ajouter l’attribut suivant : disable-output-escaping= »yes »:
<xsl:value-of select="@Valeur" disable-output-escaping="yes" />
 
Sans aller dans les tréfonds du code XLS, le Sharepoint designer peut aider à la tache :

  • Se mettre en mode « création »
  • Survoler l’un des éléments de la webpart
  • Changer le type d’affichage (passer le « texte brut » à « texte enrichi »).