Another .NET Blog

Poursuivons cette série d'articles en nous attardant désormais sur l'analyse du code des assemblies grâce à un outil que vous devez tous connaître (et si ce n'est pas le cas, je vous enjoins expressément à vous y intéresser): FxCop. D'une manière similaire à ce que nous avons fait auparavant avec les tests unitaires, nous allons là aussi "programmer" l'exécution de l'analyse dans le fichier NAnt, puis nous allons configurer Hudson pour afficher les résultats de cette analyse directement sur la page du projet.

On trouve sur internet un paquet de tutoriaux sur la configuration de divers serveurs d'intégration continue, basés sur des solutions différentes (TeamCity, Hudson, Cruise Control.NET...), avec des options différentes (FxCop, avec ou sans tests unitaires...). Le problème est que ces tutoriaux ciblent tout le temps .NET 3.5 ou 2.0 (normal me direz vous) et que les "options" proposées ne me conviennent pas, notamment concernant les tests unitaires (Personne n'utilise donc xUnit?)

Je me suis donc efforcé de faire fonctionner un serveur d'intégration continue qui remplirait les objectifs suivants:

1. Framework ciblé : .NET 4.0
2. Librairie de tests unitaires : xUnit
3. Utilisation d'outils d'analyse de code : FxCop
4. Couverture de code : nCover

Et je me propose donc de vous en relater les étapes lors de cette série d'articles.

Hier soir est sortie une nouvelle release de Code Contracts, à télécharger ici.

Pour info, la release note:

Release 1.2.30113.1 (Jan 13, 2010) Contracts

• Silverlight 4 support added, Silverlight2 dropped.
• We now have a set of contract reference assemblies for the different target frameworks (3.5, 4.0, Silverlight 3.0, Silverlight 4.0). This allows contracts on newer APIs and avoids problems where the rewriter added the wrong references to the target assembly.
• Contract invariant methods now must be private.
• Invariants on auto properties are turned into pre and post conditions of the corresponding setter and getter. This permits using auto properties with contracts.
• Added more contracts to System.Linq, System.Net, System.Collections, System.Data, System.Math namespaces
• Fixed issues of referencing v3.5 assemblies with contracts from v4.0 projects
• Tweaks to extraction of contracts from VB constructors

Runtime Checker

• Makes sure contract invariant methods are not called directly
• Object invariants are now delayed until the end of the constructor to avoid checking them prematurely
• Fixes to contract inheritance that would generate bad IL.
• Avoid FxCop warnings about catching all exceptions in OldValue expressions
• Initial support for ContractIgnoredAttribute added (see documentation)
• Fix in rewriting attributes with arrays of enums
• Fixed codegen issues when removing Assert/Assumes from code

Documentation Generation

• Fixed path problems
• Fixed inheritance problems

Static Checker

• Improved handling of IsNan
• Improved error messages now include the condition in all cases (not just for other assemblies)
• Improved interval analysis
• Improved handling of box operations
• Squigglies now work in VS2010
• Fixed handling of unicode error messages in the output
• Better handling of IntPtr and UIntPtr
• Better handling of inferred mutations at method calls
• Masking of warnings at the assembly level using SuppressMessage now supported for global warnings

Vu sur le blog de l'équipe en charge du développement du profiler pour VS2010, les nouveautés concernant la page de résumé du profiling d'une application. A lire ici.

A lire également ici, une sorte d'introduction à comment lancer une séance de profiling grâce au raccourci clavier ALT+F2

Et pour finir, leur tout dernier article explique comment lancer une session de profiling sur une série de tests unitaires.

Bonne lecture!

Si vous ne connaissez pas PEX ou Code Contracts, bonne nouvelle! Il existe un podcast en français (oui oui!) qui présente très succinctement ces 2 nouveaux outils prévus pour .NET 4.0 qui vous permettront de faciliter vos développements en TDD.

En effet, Code Contracts vous permet de définir dans le corps de vos fonctions des contrats (étonnant non?) qui vont porter sur les valeurs d'entrée et de sortie de vos fonctions. Ça vous permet d'éviter toutes ces séries de tests rébarbatives vérifiant par exemple que ArgumentNullException est bien lancée quand vous passez un null, ou qu'une fonction ne retourne jamais null. De quoi alléger un peu les test.

PEX quant à lui va vous permettre d'automatiser l'appel des fonctions avec des valeurs plus ou moins aléatoires, ce qui va vous permettre de voir dans quelle mesure vos tests unitaires couvrent bien l'intégralité des possibilités d'erreur (ou non) lorsque vous utilisez ces fonctions.

2 nouveaux outils que je trouve vraiment très intéressant et pour lesquels je pense faire prochainement des articles lorsque je commencerai à les utiliser.

Via Coq Blog.

Je profite d'en avoir parlé lors de mon dernier post pour vous donner une méthode d'extension toute faite qui vous permettra d'appeler automatiquement BeginInvoke sur le Dispatcher d'un contrôle WPF si l'action que vous voulez exécuter sur le contrôle se passe depuis un autre thread que celui sur lequel tourne l'application:

namespace System.Windows.Threading
{
    public static class DispatcherExtensions
    {
        /// 

        /// Executes the action on the thread of the UI if needed, or on the current thread if not
        /// 
        /// The Dispatcher of the control
        /// The action to execute
        /// The dispatcher or the action are null
        public static void CheckAccessAndDo(this Dispatcher dispatcher, Action action)
        {
            CheckAccessAndDo(dispatcher, DispatcherPriority.Normal, action);
        }

        /// 

        /// Executes the action on the thread of the UI if needed, or on the current thread if not
        /// 
        /// The Dispatcher of the control
        /// The priority of the action
        /// The action to execute
        /// The dispatcher or the action are null
        public static void CheckAccessAndDo(this Dispatcher dispatcher, DispatcherPriority priority, Action action)
        {
            if (dispatcher == null) throw new ArgumentNullException("dispatcher");
            if (action == null) throw new ArgumentNullException("action");

            if (dispatcher.CheckAccess())
                action();
            else
            {
                dispatcher.BeginInvoke(priority, action);
            }
        }
    }
}

Pour l'utiliser, c'est très simple et évident:

label.Dispatcher.CheckAccessAndDo(delegate { label.Content = "foo"; } );

De quoi rendre la vie plus facile :p

Après le précédent article d'introduction à la TPL et l'exemple de code de téléchargement d'un fichier sur internet, voici la suite, et fin, avec l'implémentation de la reprise, de la progression et de la fin (par annulation, ou à cause d'une erreur) du téléchargement.

Trouvée ici, une astuce vraiment *TRES* tricky, qui permet de simplifier (?) le test sur la "nullité" d'un ou plusieurs arguments, le tout à base d'expression trees et de types anonymes...

Je cherchais récemment à détecter grâce à la reflection tous les types d’une assembly qui dérivaient d’un type de base générique, afin d’utiliser une version modifiée de la factory que j’ai déjà présenté sur ce blog. Soit par exemple un type comme celui-ci: class Toto : Base<int> Pour cela, j’ai trouvé sur internet une petite fonction qui fait ça bien comme il faut:

private static bool IsTypeDerivedFromGenericType(Type typeToCheck, Type genericType)
{
	if (typeToCheck == typeof(object))
		return false;
	if (typeToCheck == null)
		return false;
	if (typeToCheck.IsGenericType && typeToCheck.GetGenericTypeDefinition() == genericType)
		return true;
		
	return IsTypeDerivedFromGenericType(typeToCheck.BaseType, genericType);
}

A l’utilisation, on a donc:

Assembly assembly = Assembly.GetExecutingAssembly();

// Loop each type in assembly
foreach (Type type in assembly.GetTypes())
{
	if (type.IsClass && !type.IsAbstract && IsTypeDerivedFromGenericType(type, typeof(GenericManager<>)))
	{
		//...
	}
}

A mettre d’urgence dans votre DLL à tout faire!

J'avais donné dans mon article précédent un lien expliquant comment utiliser plusieurs Expect pour une même fonction.

Il se trouve que j'aurais dû être plus consciencieux dans mon article, puisqu'un test unitaire se devait vraiment d'utiliser cette fonctionnalité très puissante de Moq.

En voici la preuve...