Não foi possível encontrar nenhum recurso apropriado para a cultura especificada ou a cultura neutra

194

Eu tenho dois projetos da Web do ASP.NET (ProjectA e ProjectB). Quando a classe no ProjectA está instanciando uma classe do ProjectB que usa um arquivo de recurso Blah.resx, recebo este erro:

Uma exceção do tipo 'System.Resources.MissingManifestResourceException' ocorreu no mscorlib.dll, mas não foi tratada no código do usuário.

Não foi possível encontrar nenhum recurso apropriado para a cultura especificada ou a cultura neutra. Verifique se "Resources.Blah.resources" foi corretamente incorporado ou vinculado ao assembly "App_GlobalResources.sn_flri6" no tempo de compilação ou se todos os assemblies de satélite necessários são carregáveis ​​e totalmente assinados.

O que está causando isso?

Há um artigo no site da Microsoft sobre este http://support.microsoft.com/kb/318603 que sugere:

Para resolver esse problema, mova todas as outras definições de classe para que apareçam após a definição de classe do formulário.

Esta é uma solução para o projeto Windows Forms, não tenho certeza se isso também se aplica a projetos da Web.

desenvolvedor
fonte
Que tipo de projetos são esses? 2 sites? 1 site, uma biblioteca de classes?
Ruddy
Dois projetos de site ASP.NET.
precisa saber é o seguinte
11
+1 para o To resolve this problem, move all of the other class definitions so that they appear after the form's class definition.Isso resolveu o meu problema.
OmarOthman 25/10
1
Marque com +1 sua definição de perguntas com o link Ajuda do Microsoft Windows.Forms Project apenas corrigiu meu problema.
DarrenMB
Esta resposta resolveu o problema para mim! GetGlobalResourceObject
precisa saber é o seguinte

Respostas:

257

Acabei de atingir essa mesma exceção em um projeto WPF. O problema ocorreu em um assembly que recentemente mudamos para outro espaço de nome ( ProblemAssembly.Supportpara ProblemAssembly.Controls). A exceção estava acontecendo ao tentar acessar recursos de um segundo arquivo de recurso que existe no assembly.

Acontece que o arquivo de recurso adicional não moveu adequadamente as referências do nome antigo do espaço para nome para o novo nome.

No designer.cs do arquivo de recurso, há uma propriedade estática para obter o ResourceManager. Nesse getter, a string ainda estava se referindo ao antigo namespace. Depois de corrigi-lo no novo espaço para nome, o problema foi resolvido:

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

deveria ter ficado:

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

Espero que isso ajude a próxima pessoa.

CFinck
fonte
5
+1 Boa explicação de onde localizar a causa no arquivo do designer. Encontrados e corrigidos mesmo problema graças a você :)
Ido Codificação
1
link: documentação do MSDN para a classe ResourceManager .
Boinst 26/07/12
3
Obrigado, me ajudou a resolver esse problema. Também é possível excluir o arquivo de designer, abrir e salvar o arquivo resx para gerar novamente o arquivo de designer corretamente.
Serge
1
Eu tive o mesmo problema e esta foi a resposta que estava procurando. Infelizmente, ele não aparece no momento da compilação :-( Obrigado
noob
2
obrigado também teve esse problema, mas foi porque adicionei uma subpasta com o mesmo nome da última parte do espaço para nome do projeto, procurando por project.folder.folder.class em vez de project.folder.class. Mudei-o para a raiz e agora ele se alinha e funciona!
SelAromDotNet
115

Eu resolvi o problema assim:

  1. Clique com o botão direito do mouse no seu ResourceFile
  2. Altere a propriedade "Build Action" Compile para "Embedded Resource"
  3. Então construa e execute

Funciona perfeitamente.

Sibi Elango
fonte
@sibi Elango Clico com o botão direito do mouse no meu ResourceFile, mas não consigo encontrar a parte Build Action.
S5498658
1
@ S5498658 Se você não vir isso no menu de contexto (clique com o botão direito do mouse), procure no painel Propriedades (geralmente localizado abaixo do Solution Explorer).
define
Sua ação de compilação, mas ainda não está funcionando. Também verifiquei o diretório e o diretório é o mesmo nas propriedades.
albatroz
1
Seria ótimo se a resposta explica por que essa solução funciona.
Luis Teijon 30/06
isso é simplesmente incrível
code4j 3/17/17
22

Quando tentei compartilhar um arquivo resource.resx de um projeto C # com outro projeto C #, obtive esse problema. A sugestão de mover a classe Form para o início de seu arquivo não era apropriada. Foi assim que eu resolvi. Você basicamente usa um link do segundo projeto para o primeiro e ativa a regeneração do resource.designer.csarquivo.

  1. Exclua o Properties/Resources.resxarquivo do segundo projeto
  2. Adicione o Properties/Resources.resxarquivo do primeiro projeto como um LINK à pasta Propriedades no segundo projeto. Não o adicione ao nível raiz do projeto.
  3. Não adicione os primeiros projetos Properties/Resources.designer.cs!
  4. Nas propriedades do segundo projeto Resources.resx, adicione ResXFileCodeGeneratorcomo CustomTool
  5. Clique com o botão direito do mouse Resources.resxe selecione "Executar ferramenta personalizada". Isso irá gerar um novo arquivo designer.cs.

Nota: Evitaria editar o arquivo resource.designer.cs, pois isso é gerado automaticamente.

Mark Lakata
fonte
12

No meu caso, uma série de substituições de texto globais mal pensadas alteraram inadvertidamente essa linha no arquivo cs do designer de recursos.

insira a descrição da imagem aqui

Como o espaço para nome nesse argumento não correspondia mais ao espaço para nome da classe, o aplicativo ficou confuso em tempo de execução.

Verifique se o espaço para nome do designer corresponde ao argumento da string nessa linha.

cockypup
fonte
1
foi exatamente o meu problema. Obrigado por compartilhar!
AcidJunkie
O mesmo aqui: aconteceu após a migração do PCL para o .NET Standard, quando criei um projeto e espaço para nome temporários, nos quais copiei todos os arquivos portáteis, removi o projeto portátil e reverti o espaço para o original, essa linha ainda continha o temporário namespace do processo de migração.
Zerga 02/10/19
11

Isso acontece porque o *.resхé excluído da migração.

  • Clique com o botão direito do mouse no seu ResourceFile
  • Clique no item de menu "Incluir no projeto"
user1919359
fonte
2
Isso consertou para mim. Normalmente, o arquivo resx é adicionado automaticamente. Eu fiz uma mesclagem onde eu tive que mudar o arquivo de projeto e adicione as migrações manualmente, talvez isso tinha algo a ver com isso
smarty
Trabalhou para mim. Eu tenho que adicionar todos os arquivos * .resx de cada migração. Graças
m.rufca
7

Descobri que excluir o arquivo designer.cs, excluir o arquivo resx do projeto e incluí-lo novamente, geralmente corrigia esse tipo de problema, após uma refatoração de espaço para nome (conforme resposta do CFinck)

Stephen Drew
fonte
Foi isso que fez por mim! (tentou a resposta de CFinck como parecia relevante, mas não funcionou)
Winwaed
Na verdade uma das soluções mais rápidas
Lorenz Lo Sauer
6

Ninguém parece ter mencionado essa solução. Óbvio realmente - mas me tropeçou por um momento ...

O modificador de acesso padrão para um novo arquivo de recursos é Internal(ou Friendno VB.Net.) Certifique-se de alterar isso paraPublic

(no designer resx, há uma lista suspensa na parte superior do modificador de acesso)

James S
fonte
4

A resposta de Sibi Elangos sozinha não foi suficiente para mim, então eu tive que

  • Clique com o botão direito do mouse no seu ResourceFile
  • Altere a propriedade "Build Action"
  • Compilar para "Recurso incorporado"
  • Construir e implantar

Isso irá gerar um App_GlobalResources na sua /binpasta, agora copie essa pasta também para a raiz do aplicativo Web

AlexanderD
fonte
4

No meu caso, o problema causado pela definição de classe da maneira errada:

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
    {
    }
}

Depois de realocar BackendObjectpara o final (melhor separar o arquivo), a limpeza do projeto + a reconstrução resolveram o problema.

Jawad Al Shaikh
fonte
1
Uau, eu não sabia que ter a classe errada no início do arquivo quebraria muito as coisas.
BrainStorm.exe
4

Resolvi isso indo para o projeto em que meu arquivo de recursos foi salvo, rolando para baixo até o ItemGroup e adicionando um nome lógico que correspondia ao caminho que o compilador esperava.

Meu EmbeddedResource ficou assim:

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

Agora parece com isso

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

No que diz respeito a este caso, verifique se o assembly que contém recursos possui o espaço para nome padrão definido como o mesmo texto (Projeto-> Propriedades-> Espaço para nome padrão; no VS) Verifique também se o arquivo resx tem uma propriedade BuildAction definida como "Embedded recurso "Aproveite ...;)

Mohammad Fazeli
fonte
1
Oi, você quer dizer que o espaço para nome padrão (xxx) texto deve ser o mesmo que no código: Assembly localisationAssembly = Assembly.Load("xxx"); ResourceManager resourceManager = new ResourceManager("xxx", localisationAssembly);
DanielV
2

Uma abordagem seria colocar as classes / recursos compartilhados em um projeto separado da biblioteca de classes e encaminhá-los para os dois sites.

Subbu
fonte
2
Certamente este é o mesmo problema, não é?
Brett Rigby
2

Obrigado @CFinck! Apenas para adicionar uma dica a outras pessoas: alterei a linha ResourceManager com esta:

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

Estou no vb.net, mas acho que em C # a única diferença seria + em vez de & para concatenar seqüências de caracteres.

Dessa forma, posso usar os mesmos arquivos de montagem vinculados em dois projetos semelhantes que compartilham os recursos.

Mathieu Leblanc
fonte
1

Esse erro também é gerado pelo Dotfuscation, pois um arquivo de designer resx depende de reflexão. Se você estiver usando o Dotfuscator, ele quebrará seus arquivos resx. Você sempre deve adicioná-los como uma exclusão do processo de ofuscação.

Trevor Elliott
fonte
1

Quando estávamos usando

HttpContext.GetGlobalResourceObject()

Isso geraria esse erro, a menos que agrupássemos a chamada em uma instrução try / catch.

jmb_coder
fonte
1

Eu tenho um aplicativo WinForms com um único projeto na solução.
Segmentação .NET Framework 4.0
usando SharpDevelop 4.3como meu IDE

Parece bobo, mas aconteceu que eu tinha a Logical Namepropriedade definida "Resources"no meu"Resources.resx" arquivo. Depois que limpei a propriedade, tudo funcionou bem.

Normalmente, quando você adiciona arquivos aleatórios como EmbeddedResource, geralmente deseja definir Logical Namealgo como razoável, por algum motivo, fiz o mesmo noResources.resx arquivo e isso estragou tudo ...

Espero que isso ajude alguém.

Nurchi
fonte
Eu parecia ter isso também. Um conflito de nomes eu acho, bom achado!
Trent
1

Para mim, o problema era copiar arquivos .resx e arquivos .cs associados de um projeto para outro. Ambos os projetos tinham o mesmo espaço para nome, então esse não era o problema.

Finalmente resolvi quando notei no Solution Explorer que no projeto original os arquivos .resx eram dependentes dos arquivos .cs:

MyResource.cs
|_ MyResource.resx

Enquanto no projeto copiado, os arquivos .cs dependiam dos arquivos .resx:

MyResource.resx
|_ MyResource.cs

Aconteceu que, no segundo projeto, os arquivos .resx foram configurados para gerar automaticamente os arquivos .cs. Os arquivos .cs gerados automaticamente estavam substituindo os arquivos .cs copiados do projeto original.

Para corrigir o problema, edite as propriedades de cada arquivo .resx no projeto copiado. A propriedade Custom Tool será definida como algo como ResXFileCodeGenerator . Limpe a propriedade Custom Tool do arquivo .resx. Você precisará copiar novamente o arquivo .cs do projeto original, pois ele será substituído pelo arquivo gerado automaticamente.

Simon Tewsi
fonte
1

No meu caso, eu havia colocado uma nova classe em cima de um formulário do Windows, dentro do mesmo arquivo.

Mover a classe recém-adicionada desse arquivo corrigiu o problema.

Veja aqui: http://i.stack.imgur.com/wVu6c.png

Petre
fonte
1
Bem-vindo ao Stackoverflow! Se você tiver um código para compartilhar conosco, não o publique como imagem. Você pode adicioná-lo à sua postagem e formatá-lo como código .
FelixSFD
Obrigado @FelixSFD pela sugestão
Petre
1

Isso pode ser causado por namespaces incompatíveis. A segunda da resposta superior (da Sibi Elango) diz para clicar com o botão direito do mouse no arquivo resx e alterar a opção Build para EmbeddedResource, mas eu já tinha feito isso e ainda tinha o erro. A resposta superior (CFinck's) indica uma maneira de corrigir isso através da edição manual de arquivos; no entanto, eu tive esse problema no MonoDevelop e tive que definir o espaço de nome padrão como o arquivo cs que estava chamando o recurso (o arquivo que código contido, como o código abaixo) ...

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

Após definir o espaço para nome padrão por meio da GUI, a linha acima não causou mais uma exceção.

Poikilos
fonte
1

Apenas outro caso. Copiei uma solução com dois projetos e os renomeei parcialmente no Windows Explorer (nomes de pastas, nomes de arquivo .sln e .csproj) e parcialmente com uma ação maciça de Localizar e substituir no Visual Studio (espaços de nome etc.). No entanto, a exceção declarada pelo OP ainda ocorreu. Descobri que os nomes de Assembly e Namespace ainda eram antigos.

Embora o projeto e todo o resto já tenham sido nomeados OfficeStyle o Assembly namee Default namespaceainda foram nomeados Linckus .

Situação antiga

Após essa correção, tudo funcionou bem novamente, compile e execute o tempo :)

Nova situação

Bernoulli IT
fonte
0

No meu caso, essas linhas de código adicionadas Web.configajudaram bastante:

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

Juntamente com ação de compilação: Embedded Resourcee Custom Tool: PublicResXFileCodeGenerator.

m_david
fonte
0

As propriedades Double Click na seção Application marque Nome do assembly e espaço para nome padrão são os mesmos

DevC
fonte
0

Eu também estava enfrentando o mesmo problema, tentei todas as soluções mencionadas na resposta, mas nenhuma parecia funcionar. Aconteceu que durante o check-in do código para o TFS. O TFS não fez check-in no arquivo Resx, apenas fez check-in no arquivo de designer. Portanto, todos os outros desenvolvedores estavam enfrentando esse problema enquanto rodavam em suas máquinas. Verificar o arquivo resx manualmente fez o truque

Kayani
fonte
O que você quer dizer com "check-in"?
Fandango68
Empurrando o arquivo para TFS
Kayani
0

Isso também pode ocorrer ao colocar uma classe acima da classe principal do winform (Form1, por exemplo). Você pode ver isso quando olha para o design, pois ele não é renderizado.

williamw
fonte
0

Outra causa: se o seu espaço para nome tiver um hífen ("-"), ele será criado e executado corretamente, mas o recurso não estará acessível. Os espaços para nome (identificadores) não devem ter hífens, mas isso não parece ser imposto em nenhum lugar, exceto no carregamento de recursos. Isso me queimou duas vezes ao longo da década.

beanmf
fonte
0

Outra coisa a verificar é se você tem LogicalName ou ManifestResourceName definido no EmbeddedResource. Certifique-se de que elas estejam definidas adequadamente se o arquivo do projeto as estiver usando, pois elas podem fazer com que os recursos permaneçam com um nome que você não está esperando.

David Engel
fonte
0

Eu enfrentei esse problema ao executar o comando de migração. Update-Databaseno console do Package Manager.

A resposta aceita não resolveu meu problema.

Eu tive que mudar o Build Action de Compilepara Embedded Resourcee funcionou para mim.

Você pode fazer o mesmo usando as etapas abaixo:

  1. Clique com o botão direito do mouse na migração.
  2. Altere a propriedade "Compilar ação" "Compilar" para "Recurso incorporado"
  3. Execute o comando Update-Database.
immirza
fonte
0

Para usuários que enfrentam esse problema no .NET Core 3.0, isso pode estar relacionado a uma alteração de última hora feita no .NET Core 3.0, para resolvê-lo apenas definido EmbeddedResourceUseDependentUponConventioncomo falso no seu projeto csproj:

<PropertyGroup>
  <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
</PropertyGroup>
Soheil Alizadeh
fonte
0

Clique com o botão direito do mouse nos recursos e selecione Run Custom Tool

Isso corrigirá o designer

Michele Bortot
fonte
-1

Só porque você está fazendo referência à DLL do Projeto B não significa que o Gerenciador de Recursos do Projeto A esteja ciente do diretório App_GlobalResources do Projeto B.

Você está usando projetos de sites ou aplicativos de web? No último, o Visual Studio deve permitir que você vincule arquivos de código-fonte (não tenho certeza sobre o primeiro, nunca os usei). Este é um recurso pouco conhecido, mas útil, descrito aqui . Dessa forma, você pode vincular os arquivos de recurso do Projeto B ao Projeto A.

Heinzi
fonte