Je pense que cela dépend de l'objectif des méthodes d'extension.

• Les méthodes d'extension liées aux besoins métier spécifiques d'un projet (qu'elles soient liées à des types de données de base ou à des objets personnalisés) ne doivent pas être incluses dans une bibliothèque qui serait distribuée sur plusieurs projets.
• Les méthodes d'extension liées aux types de données de base (int, chaîne, etc.) ou aux génériques ayant une application plus large peuvent être empaquetées et distribuées à travers les projets.

Veillez à ne pas inclure globalement les méthodes d'extension qui ont peu d'application, car elles ne font qu'engorger Intellisense et peuvent prêter à confusion et/ou à une mauvaise utilisation.

J'ai inclus mes méthodes d'extension avec mes bibliothèques Core dans la classe Utils parce que les personnes qui travaillent avec mon framework trouveront probablement les méthodes utiles, mais pour un déploiement de masse où le développeur final peut avoir le choix de l'extension bibliothèques de méthodes, je vous conseillerais de placer toutes vos extensions dans leur propre espace de noms, même leur propre fichier de projet, afin que les utilisateurs puissent choisir d'ajouter une référence ou une instruction using ou simplement si nécessaire, comme ceci :

Core.Extensions.Base64Encode(str);

Ma classe Utils est mon meilleur ami dans le monde entier, c'était avant que les méthodes d'extension n'arrivent et elles n'ont fait que renforcer notre relation. La règle la plus importante que je suivrais est de donner aux gens le choix du framework d'extension qu'ils utilisent dans la mesure du possible.