- La vidéo
- La tablature
Amorphis – House Of Sleep
- Les réglages POD HD500
Tones House of Sleep
Pour fêter le passage de Rammstein à Paris, une petite cover !
Il arrive régulièrement de devoir écrire une méthode générique qui accepte n’importe quel type Enum comme paramètre.
Voici un exemple de cas où cela peut s’avérer nécessaire.
Il s’agit rendre générique une méthode LogError, dont le second paramètre est un type Enum, qui permet de spécifier la catégorie :
public enum LogCategory
{
Default,
UserInterface,
BusinessLogic,
DataAccess,
Security,
Errors
}
Cette classe LogCategory est définie dans une librairie de classes (par exemple DataAccess). On a également une application web (par exemple Web1) qui appelle cette méthode LogError pour la loguer mais le problème c’est que cette application web a elle-même défini sa propre classe LogCategory.
Donc lorsque l’énumération LogCategory de Web1 est passée en paramètre de la méthode LogError, cela génère une erreur de compilation Cannot convert Web1.LogCategory into DataAccess.LogCategory car il s’agit bien entendu de deux classes différentes dans deux projets différents.
Il est donc nécessaire de créer une méthode LogError générique qui accepterait n’importe quel énumération comme paramètre.
Voici une première version de cette méthode :
public static void LogError<T>(string msg, T logCat)
{
//Here T is generic type.
EntLib.Logger.Write(msg, logCat.ToString(), 3, 1000, TraceEventType.Error);
//EntLib = Microsoft.Practices.EnterpriseLibrary.Logging;
}
Mais cette méthode est devenue trop générique car T peut être de n’importe quel type. Il est donc nécessaire d’ajouter une contrainte sur le type de T afin de le limiter à des énumérations, grâce à l’utilisation de la clause where.
public static void Error<T>(string msg, T logCat) where T: Enum
{
//Here T is generic type.
EntLib.Logger.Write(msg, logCat.ToString(), 3, 1000, TraceEventType.Error);
//EntLib = Microsoft.Practices.EnterpriseLibrary.Logging;
}
Mais cela ne fonctionne pas, car cela génère une erreur de compilation Type Expected. Apparemment il n’y a pas de manière simple de spécifier une contrainte sur une énumération. Étant donné que le type Enum implémente l’interface IConvertible, une solution de contournement pourrait être de créer une contrainte sur cette interface :
public static void Error<T>(string msg, T logCat) where T: struct, IConvertible
{
//Here T is generic type.
EntLib.Logger.Write(msg, logCat.ToString(), 3, 1000, TraceEventType.Error);
//EntLib = Microsoft.Practices.EnterpriseLibrary.Logging;
}
Cela limite un peu le type de paramètre, l’instruction LogError<SomeXClass>("message", objOfSomeXClass) génère une erreur de compilation :
The type ‘SomeXClass’ must be a non-nullable value type in order to use it as parameter ‘T’ in the generic type or method ‘LogError<T>(string, T)’
C’est mieux , il est toujours possible de passer un objet d’un type implémentant l’interface IConvertible mais c’est plutôt rare.
Il est également possible de vérifier dans le code le type de T afin de valider qu’il est bien de type Enum et restreindre encore plus.
Version finale :
public static void Error<T>(string msg, T logCat) where T : struct, IConvertible
{
if (!typeof(T).IsEnum)
{
string errorMessage = string.Format("{0} must be an enumerated type", typeof(T).ToString());
throw new ArgumentException(errorMessage, typeof(T).ToString());
}
EntLib.Logger.Write(msg, logCat.ToString(), 3, 1000, TraceEventType.Error);
//EntLib = Microsoft.Practices.EnterpriseLibrary.Logging;
}
Source : Shailesh sur Broken Code.
Il y a un raccourcis clavier que je définis systématiquement sur toutes les Visual Studio que j’utilise, parce qu’il est génial et fais gagner un temps fou.
Il s’agit de « Afficher la balise active » : lorsqu’on tape le nom d’une classe dont le namespace n’est pas définit dans les using en entête de fichier, ou que l’on renomme une classe, méthode ou variable, un petit symbole s’affiche sous le nom de la classe :
![]()
Si l’utilisateur clique sur ce symbole, un menu contextuel apparait, proposant notamment d’ajouter l’instruction using dans l’entête ou de renommer toutes les références :

En fait ce raccourci existe déjà par défaut mais n’est pas très pratique à taper : Shift + Alt + F10 ou Ctrl+;. Ces raccourcis là ont tendance à casser le flux lorsque l’on tape des instructions.
Je suggère fortement de le remplacer par Alt + Espace qui est nettement plus pratique !
Pour changer ce raccourci clavier dans la Visual Studio 2010 :
Outils, sélectionner Options...Environnement et sélectionner ClavierAfficher les commandes contenant, taper Affichage.Afficherlabaliseactive ou View.Showsmarttag pour une VS en anglaisAppuyer sur les touches de raccourci, taper le raccourci Alt + EspaceUtiliser un nouveau raccourci dans a bien pour valeur GlobalAssignerCe raccourci sera désormais disponible sur n’importe quelle fenêtre de la Visual Studio, à partir du moment qu’une balise active est disponible.
Je suis tombé récemment sur quelques guides détaillant la meilleure manière d’enchaîner les différents effets, ils m’ont semblé suffisamment intéressants pour que je note les liens dans un coin.
Bien entendu, il s’agit juste d’indications et qu’il est possible de faire autrement, en fonction du son que l’on veut obtenir. C’est juste une présentation de l’enchaînement « classique ».
La dernière version de la Visual Studio a un petit bug (certains diront probablement « fonctionnalité ») : souvent, lorsque l’on interrompt l’exécution de l’application (bouton « pause », ctrl-break…) afin de modifier le code pendant le débogage, la Visual Studio affiche un peu trop souvent un nouvel onglet No source available, indiquant que la source du code n’est pas disponible (notamment parce application était inactive, donc aucun code n’est exécuté…).
Le problème, c’est que c’est un peu ennuyeux, cet onglet n’apporte rien et il faut ensuite retrouver l’onglet sur lequel on était. L’idéal serait tout de même que la Visual Studio laisse l’utilisateur là où il était, ou du moins que ce soit quelque chose de paramétrable.
En attendant que Microsoft se bouge, quelqu’un a écrit une extension permettant de supprimer cette fenêtre : Disable No Source Available Tab.
Ce n’est pas une solution idéale car l’onglet s’affiche généralement furtivement avant de disparaître et d’après mon expérience, cela ne fonctionne pas à tous les coups, mais c’est déjà ça !
Je me suis récemment lancé dans le développement en WPF et MVVM et j’ai vite constaté un problème : c’est bien beau tout ce binding de propriétés, tout ces éléments automatiques mais du coup cela devient très difficile de suivre ce qu’il se passe, de mettre des points d’arrêt et de déboguer tout ce petit monde.
Pour cela, j’ai trouvé pas mal d’outil permettant de pallier ce problème. D’ailleurs je n’ai pas trouvé grand chose qui soit réellement intégré à la Visual Studio, j’imagine que c’est encore un peu trop « récent » pour que Microsoft soit correctement outillé.
Bref, le meilleur outil que j’ai trouvé à ce jour, c’est WPF Inspector.
Le principe (pour ce logiciel et généralement pour les autres) : il s’agit d’une application standalone qui affiche la liste des applications WPF actuellement lancées afin de s’attacher à son processus. Une fois la liaison établie, l’outil affiche une arborescence des éléments de l’application (fenêtres, contrôles…) avec toutes leurs propriétés.
Elle permet donc :
DataContext et ainsi pouvoir analyser les objets sur lesquels sont mappés les contrôles, ce qui facilite l’identification de problèmes de binding,Cet outil m’a plusieurs fois sauvé la mise, donc je le recommande chaudement.
Il y a également un autre outils du même acabit : Snoop – the WPF Spy Utility qui semble fournir à peu près les mêmes fonctionnalités que WPF Inspector.
Afin d’améliorer l’affichage de mes articles et notamment pour pouvoir ajouter des petits bouts de code directement dans le texte de mes articles (« inline »), je souhaitais avoir quelque chose qui ressemble à ce qui existe sur Stack Overflow, à savoir pouvoir encadrer un bout de texte avec des « backquotes » afin d’avoir un affichage particulier.
N’ayant pas trouvé de plugin satisfaisant dans le répertoire de plugins du site de WordPress (il existe des plugins pour ajouter la syntaxe Markdown mais je n’étais intéressé que par cette fonctionnalité spécifique), j’ai décidé de créer le mien, kg-inline-code.
Bien entendu, je suis ouvert à toute suggestion d’amélioration (notamment au niveau de l’expression régulière, qui peut probablement être améliorée).
Dans la dernière version de ASP.NET, une fonctionnalité vraiment pratique est apparue : la transformation XML du fichier web.config.
C’est une fonctionnalité toute bête et pourtant très pratique : elle permet de modifier le fichier de configuration en fonction de l’environnement cible utilisé pour la compilation / publication du projet.
La mise en œuvre est simple, il suffit d’ajouter au projet des fichiers web.[environnement_cible].config et d’inclure dans ces fichiers les instructions de modification (ajout de clés, changements de valeurs, suppression de clés).
Malheureusement, cette fonctionnalité n’est pas disponible pour les applications lourdes (WinForm, WPF) et leur App.Config. Enfin, pas nativement.
En effet, la structure du fichier est proche et tout ce qui est fait, c’est simplement modifier des éléments d’une structure XML, rien d’extraordinaire et il n’y a donc pas de raison que ce ne soit pas possible. Donc même si l’interface de la Visual Studio ne fournit pas ces fonctionnalités, il existe forcément un moyen !
Bon apparemment, il en existe même plusieurs car dans mes recherches j’ai croisé plusieurs plugins Visual Studio ou billets de blog expliquant l’une ou l’autre technique. J’en ai essayé plusieurs sans succès (certaines ne fonctionnent pas avec tous les modes de publication, notamment ClickOnce).
Voici une solution que j’utilise quotidiennement sur un projet donc qui semble fonctionner, même avec ClickOnce. La solution est fournie par le billet de ExceptionalCode dont je me suis fortement inspiré pour cet article.
Toute la magie réside dans le projet MSBuild (AppConfig.Transformation.targets / Copie locale du fichier au 10/01/2012) créé par João Angelo de ExceptionalCode.
Il faut donc ajouter ce fichier au projet, pour cela il faut éditer le fichier du projet de démarrage:
Décharger le projet (Unload Project)Editer [nom du projet]. Cette action va ouvrir le fichier XML du projet et permettre son édition. ...
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Target Name="BeforeBuild">
</Target>
<Target Name="AfterBuild";>
</Target>
</Project>
Après modification :
...
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Import Project="..\Librairies\AppConfig.Transformation.targets" />
<Target Name="BeforeBuild">
</Target>
<Target Name="AfterBuild">
</Target>
</Project>
Ici je considère que le fichier AppConfig.Transformation.targets se trouve dans un répertoire Librairies à la racine de la solution, dans le répertoire parent du projet.
Et voilà, il ne reste plus qu’à créer un fichier de configuration pour chaque environnement cible, en respectant le format de nommage App.[environnement_cible].config comme ici :

Par contre, en suivant la procédure jusqu’ici, par défaut la Visual Studio n’affiche pas les différents fichiers App.[env].config de manière hiérarchique comme c’est le cas sur la capture d’écran ci-dessus.
Pour cela, il faut :
App.[env].config, par exemple :
<None Include="App.Debug.config" />
App.config bien sûr), il faut ajouter un sous-élément indiquant que ce fichier est dépendant de App.config
<None Include="App.Debug.config">
<DependentUpon>App.config</DependentUpon>
</None>
Lorsque le projet sera rechargé, tous les fichiers de configuration seront bien affichés de manière hiérarchique sous App.config.
Les instructions de modification à mettre dans ces fichiers sont détaillées ici et seront peut-être l’objet d’un autre billet.