Chaque évolution de .net, apporte son lot de nouvelles syntaxes pour C# ou VB. Parmi celles-ci, il en existe certaines qui peuvent vous compliquer la vie. Je vous propose aujourd’hui de décortiquer une syntaxe destinée à nous aider : "using static". Vous découvrirez les soucis qui peuvent en résulter et les dangers auxquelles celle-ci vous expose.

Pour l’exemple, j’utilise une simple classe disposant d’une unique méthode statique.

namespace Demo.ClassLibrary
{
    public class Class1
    {
        public static void Methode1()
        {

        }
    }
}

En C#, l’usage du "using static" est relativement simple. Il suffit d’utiliser la classe comme s’il s’agissait d’un namespace. Ensuite, on peut appeler les méthodes statiques de cette classe sans spécifier celle-ci (comme si la méthode statique faisait partie de la classe appelante).

using static Demo.ClassLibrary.Class1;

namespace Demo
{
    internal class Program
    {
        public void DoSomething()
        {
            Methode1();
        }
    }
}

En VB, l’approche est encore plus simple (aucun mot clé n’est requis devant Imports).

Imports Demo.ClassLibrary.Class1

Friend Class Program
    Sub DoSomething()
        Methode1()
    End Sub
End Class

En l’état, tout semble simple et trivial. Si l’on effectue un peu de refactoring sur les méthodes de notre classe (Class1), tout va bien.

La problématique

Mais que se passe-t-il si notre librairie est référencée dans un autre projet via Nuget, ou si la DLL est référencée directement ?

Le projet utilisant la DLL n’a pas moyen d’être informé du refactoring.

La compilation produira le message suivant :

Error BC30451 'Methode1' is not declared. It may be inaccessible due to its protection level.

Visual Studio proposera une solution pour fixer le problème si le refactoring a été léger :

• Renommage de la méthode avec un nom approchant
• Changement des arguments (types, ordre ou nombre d’arguments)
• Changement du type de retour.

Mais si le refactoring a été plus lourd ou si utilisez beaucoup de classes via using static / imports, Visual Studio ne pourra rien pour vous. Le message d’erreur sera le même. Ceci quel que soit le refactoring effectué sur les classes importées.

Pire : Visual Studio grisera les lignes using static / imports concernées. Pour Visual Studio, ces lignes ne sont pas utiles.

Si le refactoring conduit à ce que plusieurs méthodes partagent le même nom, et la même signature, le message d’erreur sera encore plus ambigu.

Moralité

Attention quand vous utilisez ce type de syntaxe. Pensez toujours à la lisibilité du code. Dans le cas présent, un développeur voulant résoudre le problème ne sera jamais en mesure de déterminer l’origine de la méthode manquante. De premier abord il pensera qu’une méthode a été retirée de la classe appelante. Ce qui n’est pas le cas.