Comment résoudre la System.Resources.MissingManifestResourceException pouvant se produire après un Migration .net Framework ?
Dans le cadre d'une migration d'un projet .net Framework, je me suis retrouvé avec des projets ne respectant que très peu les conventions liées aux namespaces. Plusieurs dossiers pourtant bien présents n'apparaissent pas dans les namespaces. Pour compléter le tableau, Visual Studio doit gérer des fichiers C# pour des Ressources, et formulaires WinForm présents dans ces dossiers.
Après migration de ces projets du vieux format csproj / vbproj vers le format actuel (SDK project style), les tests unitaires font remonter une erreur bien étrange :
System.Resources.MissingManifestResourceException : Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "xxxForm.resources" was correctly embedded or linked into assembly "xxx" at compile time, or that all the satellite assemblies required are loadable and fully signed.
Pour saisir l’origine du problème, je vérifie les propriétés de Ressources. Tout est à sa place. Je fais un petit tour dans dotPeek pour comparer les deux DLL avant, et après migration. Je me rends alors compte que les ressources WinFrom ne sont pas nommées de la même manière avant et après migration du projet. Les projets de tests unitaires étant encore à l’ancien format, il s’attend à ce que les ressources respectent un certain nommage.
Un petit tour dans Microsoft Learn (après une bonne heure de recherche infructueuse ici et là), je trouve le Satin Graal : How MSBuild generates manifest file names - .NET | Microsoft Learn
Cette page de documentation fait état d'un paramètre qui rétablit le comportement des namespace pour les applications .net Framework :
<EmbeddedResourceUseDependentUponConvention>true</EmbeddedResourceUseDependentUponConvention>
Après ajout de celui-ci dans le fichier vsproj / vbproj, les ressources sont correctement nommée et l'erreur ne se produit plus.
Moralité
Encore une preuve que les bonnes pratiques ne sont pas juste là pour nous embeter. Si les conventions de nommage des namespaces étaint respectées, l'exception ne se serait jamais produite.