Не удалось найти ресурсы, подходящие для указанной культуры или нейтральной культуры

У меня есть два веб-проекта ASP.NET(ProjectA и ProjectB). Когда класс в ProjectA создает экземпляр класса ProjectB, который использует файл ресурсов Blah.resx, я получаю эту ошибку:

Исключение типа "System.Resources.MissingManifestResourceException" произошло в mscorlib.dll, но не было обработано в коде пользователя.

Не удалось найти ресурсы, подходящие для указанной культуры или нейтральной культуры. Убедитесь, что "Ресурсы .Blah.resources" были правильно внедрены или связаны в сборку "App_GlobalResources.sn_flri6" во время компиляции или что все необходимые сборки спутников загружаются и полностью подписаны.

Что вызывает это?

На сайте Microsoft есть статья об этом http://support.microsoft.com/kb/318603, который предлагает:

Чтобы решить эту проблему, переместите все другие определения классов так, чтобы они отображались после определения класса формы.

Это решение для проекта Windows Forms, я не уверен, что это также относится к веб-проектам.

ОТВЕТЫ

Ответ 1

Я просто ударил это же исключение в проекте WPF. Проблема произошла в сборке, которую мы недавно переместили в другое пространство имен (ProblemAssembly.Support to ProblemAssembly.Controls). Исключение происходило при попытке доступа к ресурсам из второго файла ресурсов, который существует в сборке.

Оказывается, что дополнительный файл ресурсов неправильно перемещает ссылки из старого имени пространства имен в новое имя пространства имен.

В файле designer.cs для файла ресурсов есть свойство static, чтобы получить ResourceManager. Внутри этого получателя строка все еще ссылалась на старое пространство имен. После исправления его в новом пространстве имен проблема была решена:

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

должен был быть:

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

Надеюсь, это поможет следующему человеку.

Ответ 2

Я решил проблему следующим образом:

  • Щелкните правой кнопкой мыши свой ресурс ResourceFile
  • Измените свойство "Build Action". Скомпилируйте "Встроенный ресурс".
  • Затем выполните и запустите

Он отлично работает.

Ответ 3

Когда я попробовал поделиться файлом resource.resx с одним проектом С# с другим проектом С#, у меня возникла эта проблема. Предложение о переносе класса Form в начало его файла было неприемлемым. Вот как я это решил. Вы по существу используете ссылку от второго проекта к первому, затем включаете регенерацию файла resource.designer.cs.

  • Удалить второй проект Properties/Resources.resx file
  • Добавьте первый проект Properties/Resources.resx в качестве LINK в папку "Свойства" во втором проекте. Не добавляйте его на корневой уровень проекта.
  • Не добавить первый проект Properties/Resources.designer.cs!
  • В свойствах второго проекта Resources.resx добавьте ResXFileCodeGenerator в качестве CustomTool
  • Щелкните правой кнопкой мыши на Resources.resx и выберите "Запустить пользовательский инструмент". Это создаст новый файл designer.cs.

Примечание. Я бы не редактировал файл resource.designer.cs, так как это автогенерируется.

Ответ 4

В моем случае серия плохо продуманных глобальных текстовых замен случайно поменяла эту строку в файле cs конструктора ресурсов.

введите описание изображения здесь

Поскольку пространство имен в этом аргументе больше не соответствовало пространству имен этого класса, приложение запуталось во время выполнения.

Убедитесь, что пространство имен конструктора соответствует строковому аргументу в этой строке.

Ответ 5

Это происходит потому, что *.resх исключается из миграции.

  • Щелкните правой кнопкой мыши свой ресурс ResourceFile
  • Нажмите на пункт меню "Включить в проект"

Ответ 6

Я обнаружил, что удаление файла designer.cs, исключая файл resx из проекта, а затем повторное включение в него часто фиксировало этот вид проблемы после рефакторинга пространства имен (в соответствии с ответом CFinck)

Ответ 7

Никто, кажется, не упомянул это решение. Очевидно, на самом деле - но споткнул меня на мгновение...

Модификатором доступа по умолчанию для нового файла ресурсов является Internal (или Friend в VB.Net.). Убедитесь, что вы изменили его на Public

(в дизайнере resx вверху есть выпадающий список для модификатора доступа)

Ответ 8

Ответ Сиби Элангоса мне не хватало, поэтому мне пришлось

  • Щелкните правой кнопкой мыши свой ресурс ResourceFile
  • Измените свойство "Создать действие"
  • Скомпилировать "Встроенный ресурс"
  • Построение и развертывание

Это создаст App_GlobalResources в вашей папке /bin, теперь скопировать эту папку также в корень веб-приложения

Ответ 9

В моем случае проблема вызвана неправильным определением класса:

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

После BackendObject (лучше разделить файл) выполнение проекта clean + rebuild решило проблему.

Ответ 10

Один из подходов состоит в том, чтобы поместить общие классы/ресурсы в отдельный проект библиотеки классов и передать их на обоих веб-сайтах.

Ответ 11

Спасибо @CFinck! Просто добавьте отзыв другим: я изменил строку ResourceManager следующим образом:

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

Я нахожусь в vb.net, но я думаю, что в С# единственное различие будет + вместо и для конкатенации строк.

Таким образом, я могу использовать те же связанные файлы сборки в двух похожих проектах, которые разделяют ресурсы.

Ответ 12

Что касается этого случая, проверьте, имеет ли сборка, содержащая ресурсы, пространство имен по умолчанию для одного и того же текста (Project- > Properties- > Default namespace, в VS) Проверьте также, если файл resx имеет свойство BuildAction, установленное в "Embedded resource" Наслаждайтесь...;)

Ответ 13

Я решил эту проблему, перейдя в проект, где был сохранен мой файл ресурсов, прокрутив вниз до его ItemGroup и добавив логическое имя, которое соответствует пути, ожидаемому компилятором.

Мой EmbeddedResource выглядел так:

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

Теперь это выглядит так

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

Ответ 14

Эта ошибка также возникает при помощи Dotfuscation, поскольку файл конструктора resx основан на отражении. Если вы используете Dotfuscator, он сломает ваши файлы resx. Вы должны всегда добавлять их как исключение из процесса обфускации.

Ответ 15

Когда мы использовали

HttpContext.GetGlobalResourceObject()

Он будет генерировать эту ошибку, если мы не завершим этот вызов внутри инструкции try/catch.

Ответ 16

У меня есть приложение WinForms с одним проектом в решении.
Ориентация .NET Framework 4.0
Используя SharpDevelop 4.3 как мою IDE

Звучит глупо, но у меня было свойство Logical Name, установленное в "Resources" в моем файле "Resources.resx". Как только я очистил это свойство, все работает hunky-dory.

Обычно, когда вы добавляете случайные файлы как EmbeddedResource, вы обычно хотите установить Logical Name на что-то разумное, по какой-то причине я сделал то же самое в файле Resources.resx, и это все испортило..

Надеюсь, это поможет кому-то.

Ответ 17

Для меня проблема заключалась в копировании файлов .resx и связанных с ними файлов .cs из одного проекта в другой. Оба проекта имели одинаковое пространство имен, так что это не проблема.

Наконец, решив это, когда я заметил в Solution Explorer, что в исходном проекте файлы .resx зависели от файлов .cs:

MyResource.cs
|_ MyResource.resx

В то время как в скопированном проекте файлы .cs зависели от файлов .resx:

MyResource.resx
|_ MyResource.cs

Оказалось, что во втором проекте каким-то образом файлы .resx были настроены на автоматическое создание файлов .cs. Автогенерированные файлы .cs перезаписывали файлы .cs, скопированные из исходного проекта.

Чтобы устранить проблему, отредактируйте свойства каждого файла .resx в скопированном проекте. Свойству Custom Tool будет присвоено значение ResXFileCodeGenerator. Очистите свойство Пользовательский инструмент файла .resx. Вам нужно будет повторно скопировать файл .cs из исходного проекта, поскольку он будет перезаписан автоматически сгенерированным файлом.

Ответ 18

Просто потому, что вы ссылаетесь на DLL Project B, это не означает, что диспетчер ресурсов Project A знает каталог Project B App_GlobalResources.

Используете ли вы проекты веб-сайтов или проекты веб-приложений? В последнем случае Visual Studio должна позволять вам связывать файлы исходного кода (не уверен в первом, я никогда не использовал их). Это небольшая, но полезная функция, которая описывается здесь . Таким образом, вы можете связать файлы ресурсов проекта B с проектом A.

Ответ 19

В моем случае эти строки кода, добавленные в Web.config, помогли много:

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

Вместе с действием Build: Embedded Resource и Custom Tool: PublicResXFileCodeGenerator.

Ответ 20

Дважды щелкните свойства в разделе "Приложение" проверьте Название сборки и пространство имен по умолчанию совпадают

Ответ 21

В моем случае я разместил новый класс поверх формы Windows в том же файле.

Перенос недавно добавленного класса из этого файла устраняет проблему.

Смотрите здесь: http://i.stack.imgur.com/wVu6c.png

Ответ 22

Это может быть вызвано несогласованными пространствами имен. Второй из лучших ответов (Sibi Elango's) говорит, что нужно щелкнуть правой кнопкой мыши файл resx и изменить вариант Build на EmbeddedResource, но я уже сделал это и все еще имел ошибку. Главный ответ (CFinck's) отмечает способ исправления этого путем редактирования вручную файлов, однако у меня была эта проблема в MonoDevelop, и мне пришлось установить пространство имен по умолчанию так же, как файл cs, который вызывал ресурс (файл, который содержащий код, такой как код ниже)...

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

После установки пространства имен по умолчанию через графический интерфейс линия выше больше не вызывает исключения.

Ответ 23

Я также столкнулся с той же самой проблемой, попробовал все решения, упомянутые в ответе, но ни один, казалось, не работал. Оказалось, что во время регистрации кода в TFS. TFS не проверял файл Resx, он проверял только в файле конструктора. Таким образом, все остальные разработчики столкнулись с этой проблемой во время работы на своих машинах. Проверка в файле resx вручную сделала свое дело

Ответ 24

Это также может произойти, если поместить класс выше основного класса winform (например, Form1). Это можно увидеть, глядя на дизайн, так как он не отображается.

Ответ 25

Еще одна причина: если в вашем пространстве имен есть дефис ("-"), он будет правильно скомпилирован и запущен, но ресурс не будет доступен. Пространства имен (идентификаторы) не должны иметь дефисов, но это, кажется, не применяется нигде, кроме как при загрузке ресурсов. Это сожгло меня дважды за десятилетие.

Ответ 26

Еще одна вещь, которую нужно проверить, - это если у вас есть встроенное имя LogicalName или ManifestResourceName. Убедитесь, что они определены правильно, если ваш файл проекта использует их, поскольку они могут привести к тому, что ресурсы будут жить под именем, которое вы не ожидаете.