Impossible de trouver des ressources appropriées pour la culture spécifiée ou la culture neutre

J'ai deux projets Web ASP.NET (ProjectA et ProjectB). Lorsque la classe dans ProjectA instancie une classe de ProjectB qui utilise un fichier de ressources Blah.resx, j'obtiens cette erreur:

Une exception de type «System.Resources.MissingManifestResourceException» s'est produite dans mscorlib.dll mais n'a pas été gérée dans le code utilisateur.

Impossible de trouver des ressources appropriées pour la culture spécifiée ou la culture neutre. Assurez-vous que "Resources.Blah.resources" a été correctement incorporé ou lié dans l'assembly "App_GlobalResources.sn_flri6" au moment de la compilation, ou que tous les assemblys satellites requis sont chargeables et entièrement signés.

Qu'est-ce qui cause cela?

Il existe un article sur le site de Microsoft à propos de ce http://support.microsoft.com/kb/318603 qui suggère:

Pour résoudre ce problème, déplacez toutes les autres définitions de classe afin qu'elles apparaissent après la définition de classe du formulaire.

Il s'agit d'une solution pour le projet Windows Forms, je ne sais pas si cela s'applique également aux projets Web.

Je viens de frapper cette même exception dans un projet WPF. Le problème s'est produit dans un assembly que nous avons récemment déplacé vers un autre espace de noms ( ProblemAssembly.Supportvers ProblemAssembly.Controls). L'exception se produisait lors de la tentative d'accès aux ressources à partir d'un deuxième fichier de ressources qui existe dans l'assembly.

Il s'avère que le fichier de ressources supplémentaires n'a pas correctement déplacé les références de l'ancien nom d'espace de noms vers le nouveau nom d'espace de noms.

Dans le fichier designer.cs du fichier de ressources, il existe une propriété statique pour obtenir le ResourceManager. Dans cet getter, la chaîne faisait toujours référence à l'ancien espace de noms. Une fois corrigé dans le nouvel espace de noms, le problème a été résolu:

global::System.Resources.ResourceManager temp = 
     new global::System.Resources.ResourceManager(
          "ProblemAssembly.Support.Properties.Stuff", typeof(Stuff).Assembly);

aurait du être:

global::System.Resources.ResourceManager temp = 
     new global::System.Resources.ResourceManager(
          "ProblemAssembly.Controls.Properties.Stuff", typeof(Stuff).Assembly);

J'espère que cela aide la prochaine personne.

J'ai résolu le problème comme ceci:

1. Faites un clic droit sur votre ResourceFile
2. Modifiez la propriété "Build Action" Compile en "Embedded Resource"
3. Puis construisez et exécutez

Cela fonctionne parfaitement.

Lorsque j'ai essayé de partager un fichier resource.resx d'un projet C # avec un autre projet C #, j'ai eu ce problème. La suggestion de déplacer la classe Form au début de son fichier n'était pas appropriée. Voilà comment je l'ai résolu. Vous utilisez essentiellement un lien du deuxième projet au premier, puis activez la régénération du resource.designer.csfichier.

1. Supprimer le deuxième Properties/Resources.resxfichier du projet
2. Ajoutez le Properties/Resources.resxfichier du premier projet sous forme de LIEN au dossier Propriétés du deuxième projet. Ne l'ajoutez pas au niveau racine du projet.
3. N'ajoutez pas le premier projet Properties/Resources.designer.cs!
4. Sur les propriétés du deuxième projet Resources.resx, ajoutez en ResXFileCodeGeneratortant que CustomTool
5. Faites un clic droit sur le Resources.resxet sélectionnez "Exécuter l'outil personnalisé". Cela va générer un nouveau fichier designer.cs.

Remarque: j'éviterais de modifier le fichier resource.designer.cs, car il est généré automatiquement.

Dans mon cas, une série de remplacements de texte global mal pensés avait par inadvertance modifié cette ligne dans le fichier cs du concepteur de ressources.

Étant donné que l'espace de noms dans cet argument ne correspondait plus à l'espace de noms de la classe, l'application s'est confondue au moment de l'exécution.

Vérifiez que l'espace de noms du concepteur correspond à l'argument chaîne de cette ligne.

Cela se produit car le *.resхest exclu de la migration.

• Faites un clic droit sur votre ResourceFile
• Cliquez sur l'élément de menu "Inclure dans le projet"

J'ai trouvé que la suppression du fichier designer.cs, à l'exclusion du fichier resx du projet, puis sa ré-inclusion, corrigeait souvent ce type de problème, suite à une refactorisation de l'espace de noms (selon la réponse de CFinck)

Personne ne semble avoir mentionné cette solution. Évidemment vraiment - mais m'a fait trébucher un instant ...

Le modificateur d'accès par défaut pour un nouveau fichier de ressources est Internal(ou Frienddans VB.Net.) Assurez-vous de le changer enPublic

(dans le concepteur resx, il y a une liste déroulante en haut pour le modificateur d'accès)

La réponse de Sibi Elangos seule n'était pas suffisante pour moi, donc j'ai dû

• Faites un clic droit sur votre ResourceFile
• Modifier la propriété "Build Action"
• Compiler vers "Embedded Resource"
• Construire et déployer

Cela va générer un App_GlobalResources dans votre /bindossier, copiez maintenant ce dossier également à la racine de l'application Web

Dans mon cas, le problème causé par la définition incorrecte de la classe:

namespace MyBuggyWorld
{
    public class BackendObject //This hack broke the VS 2017 winform designer and resources linker!
    {
        public TcpClient ActiveClient { get; set; }
        public BackgroundWorker ActiveWorker { get; set; }
    }
    public partial class FormMain : Form
    {
    }
}

Après la réallocation BackendObjectà la fin (mieux vaut séparer le fichier), faire un projet propre + reconstruire a résolu le problème.

J'ai résolu cela en accédant au projet où mon fichier de ressources a été enregistré, en faisant défiler jusqu'à son ItemGroup et en ajoutant un nom logique qui correspondait au chemin que le compilateur attendait.

Mon EmbeddedResource ressemblait à ceci:

   <ItemGroup>
    <EmbeddedResource Update="Properties\TextResources.resx">
      <Generator>PublicResXFileCodeGenerator</Generator>
      <LastGenOutput>TextResources.Designer.cs</LastGenOutput>
    </EmbeddedResource>
  </ItemGroup>

Maintenant ça ressemble à ça

  <ItemGroup>
    <EmbeddedResource Update="Properties\TextResources.resx">
      <Generator>PublicResXFileCodeGenerator</Generator>
      <LastGenOutput>TextResources.Designer.cs</LastGenOutput>
      <LogicalName>MyProject.Properties.Resources.resources</LogicalName>
    </EmbeddedResource>
  </ItemGroup>

En ce qui concerne ce cas, vérifiez si l'assembly contenant des ressources a l'espace de noms par défaut défini sur le même texte (Projet-> Propriétés-> Espace de noms par défaut; dans VS) Vérifiez également si le fichier resx a une propriété BuildAction définie sur "Embedded ressource "Enjoy ...;)

Une approche consisterait à placer les classes / ressources partagées dans un projet de bibliothèque de classes distinct et à les référer sur les deux sites Web.

Merci @CFinck! Juste pour ajouter un conseil aux autres: j'ai changé la ligne ResourceManager avec ceci:

New Global.System.Resources.ResourceManager(Reflection.Assembly.GetCallingAssembly.GetName.Name & ".CommonNameOf.Resources", Reflection.Assembly.GetCallingAssembly())

Je suis sur vb.net mais je pense qu'en C # la seule différence serait + au lieu de & pour concaténer des chaînes.

De cette façon, je peux utiliser les mêmes fichiers d'assemblage liés dans deux projets similaires qui partagent les ressources.

Cette erreur est également déclenchée par Dotfuscation, car un fichier de concepteur resx repose sur la réflexion. Si vous utilisez Dotfuscator, cela cassera vos fichiers resx. Vous devez toujours les ajouter comme exclusion du processus d'obscurcissement.

Quand nous utilisions

HttpContext.GetGlobalResourceObject()

Cela générerait cette erreur, sauf si nous avons encapsulé cet appel dans une instruction try / catch.

J'ai une application WinForms avec un seul projet dans la solution.
Ciblage en .NET Framework 4.0
utilisant SharpDevelop 4.3mon IDE

Cela semble idiot, mais il se trouve que la Logical Namepropriété est définie "Resources"sur mon "Resources.resx"fichier. Une fois que j'ai effacé cette propriété, tout fonctionne doris.

Normalement, lorsque vous ajoutez des fichiers aléatoires en tant que EmbeddedResource, vous voulez généralement définir Logical Namequelque chose de raisonnable, pour une raison quelconque, j'ai fait la même chose sur le Resources.resxfichier et cela a tout foiré ...

J'espère que cela aide quelqu'un.

Pour moi, le problème était la copie des fichiers .resx et des fichiers .cs associés d'un projet à un autre. Les deux projets avaient le même espace de noms, ce n'était donc pas le problème.

Enfin résolu le problème lorsque j'ai remarqué dans l'Explorateur de solutions que dans le projet d'origine, les fichiers .resx dépendaient des fichiers .cs:

MyResource.cs
|_ MyResource.resx

Dans le projet copié, les fichiers .cs dépendaient des fichiers .resx:

MyResource.resx
|_ MyResource.cs

Il s'est avéré que dans le deuxième projet, les fichiers .resx avaient été définis pour générer automatiquement les fichiers .cs. Les fichiers .cs générés automatiquement remplaçaient les fichiers .cs copiés à partir du projet d'origine.

Pour résoudre le problème, modifiez les propriétés de chaque fichier .resx du projet copié. La propriété de l' outil personnalisé sera définie sur quelque chose comme ResXFileCodeGenerator . Désactivez la propriété Outil personnalisé du fichier .resx. Vous devrez recopier le fichier .cs du projet d'origine car il aura été écrasé par le fichier généré automatiquement.

Dans mon cas, j'avais placé une nouvelle classe au-dessus d'un formulaire Windows, dans le même fichier.

Le déplacement de la classe nouvellement ajoutée hors de ce fichier a résolu le problème.

Voir ici: http://i.stack.imgur.com/wVu6c.png

Cela peut être dû à des espaces de noms incompatibles. La deuxième réponse du haut (Sibi Elango) dit de cliquer avec le bouton droit sur le fichier resx et de changer l'option Build en EmbeddedResource, mais je l'avais déjà fait et j'avais toujours l'erreur. La réponse du haut (CFinck) note un moyen de résoudre ce problème via la modification manuelle des fichiers, cependant, j'ai eu ce problème dans MonoDevelop, et j'ai dû définir l'espace de noms par défaut sur le même que le fichier cs qui appelait la ressource (le fichier qui contient du code tel que le code ci-dessous) ...

this.Icon = ((System.Drawing.Icon)(resources.GetObject("$this.Icon")));

Après avoir défini l'espace de noms par défaut via l'interface graphique, la ligne ci-dessus ne provoque plus d'exception.

Juste un autre cas. J'ai copié une solution avec deux projets et les ai renommés partiellement dans l'explorateur Windows (noms de dossier, noms de fichiers .sln et .csproj) et partiellement avec une action de recherche et remplacement massive dans Visual Studio (espaces de noms, etc.). Néanmoins, l'exception mentionnée par le PO s'est toujours produite. J'ai découvert que les noms de l'assembly et de l'espace de noms étaient toujours anciens.

Bien que le projet et tout le reste était déjà nommé OfficeStyle le Assembly nameet Default namespaceétaient encore nommés Linckus .

Après cette correction, tout s'est à nouveau bien passé, compilez et exécutez :)

Dans mon cas, ces lignes de code Web.configont beaucoup aidé:

<system.web>
     ...
    <globalization uiCulture="cs" culture="cs-CZ" />
     ...
<system.web>

Ensemble , avec l' action de construction: Embedded Resourceet outil personnalisé: PublicResXFileCodeGenerator.

Les propriétés du double clic dans la section Application vérifient que le nom de l' assembly et l' espace de noms par défaut sont identiques

J'étais également confronté au même problème, j'ai essayé toutes les solutions mentionnées dans la réponse, mais aucune ne semblait fonctionner. Il s'est avéré que lors de l'archivage du code vers TFS. TFS n'a pas archivé le fichier Resx, il l'a uniquement archivé dans le fichier de concepteur. Tous les autres développeurs étaient donc confrontés à ce problème lors de l'exécution sur leurs machines. L'archivage manuel du fichier resx a fait l'affaire

Cela peut également se produire lorsque vous placez une classe au-dessus de la classe winform principale (Form1, par exemple). Vous pouvez le voir lorsque vous regardez la conception, car elle ne parvient pas à être rendue.

Encore une autre cause: si votre espace de noms a un trait d'union ("-"), alors il se construira et s'exécutera correctement, mais la ressource ne sera pas accessible. Les espaces de noms (identificateurs) ne sont pas censés avoir de tirets, mais cela ne semble être appliqué nulle part, sauf dans le chargement des ressources. Cela m'a brûlé deux fois au cours de la décennie.

Une autre chose à vérifier est de savoir si LogicalName ou ManifestResourceName est défini sur EmbeddedResource. Assurez-vous que ceux-ci sont définis de manière appropriée si votre fichier de projet les utilise car ils peuvent faire en sorte que les ressources vivent sous un nom que vous n'attendez pas.

J'ai rencontré ce problème lors de l'exécution de la commande de migration. Update-Databasedans la console du gestionnaire de packages.

La réponse acceptée n'a pas résolu mon problème.

J'ai dû changer Build Action de Compileà Embedded Resourceet cela a fonctionné pour moi.

Vous pouvez faire de même en utilisant les étapes ci-dessous:

1. Faites un clic droit sur la migration.
2. Modifiez la propriété "Build Action" "Compile" en "Embedded Resource"
3. Exécutez la commande Update-Database.

Pour les utilisateurs confrontés à ce problème dans .NET Core 3.0, cela pourrait être lié à une modification de rupture apportée dans .NET Core 3.0, pour le résoudre, définissez simplement la valeur EmbeddedResourceUseDependentUponConventionfalse dans votre projet csproj:

<PropertyGroup>
  <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
</PropertyGroup>

Faites un clic droit sur les ressources et sélectionnez Run Custom Tool

Cela corrigera le concepteur

Ce n'est pas parce que vous référencez la DLL du projet B que le gestionnaire de ressources du projet A connaît le répertoire App_GlobalResources du projet B.

Utilisez-vous des projets de site Web ou des projets d'application Web? Dans ce dernier, Visual Studio devrait vous permettre de lier des fichiers de code source (je ne suis pas sûr du premier, je ne les ai jamais utilisés). Il s'agit d'une fonctionnalité peu connue mais utile, qui est décrite ici . De cette façon, vous pouvez lier les fichiers de ressources du projet B au projet A.