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

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

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

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

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

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

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

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

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

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

В файле designer.cs для файла ресурсов есть статическое свойство для получения 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);

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

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

1. Щелкните правой кнопкой мыши на вашем ResourceFile
2. Измените свойство «Build Action» Compile на «Embedded Resource»
3. Тогда построй и запускай

Работает отлично.

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

1. Удалить Properties/Resources.resxфайл второго проекта
2. Добавьте Properties/Resources.resxфайл первого проекта в качестве ССЫЛКИ в папку « Свойства » во втором проекте. Не добавляйте его на корневой уровень проекта.
3. Не добавляйте первый проект Properties/Resources.designer.cs!
4. В свойствах второго проекта Resources.resxдобавьте ResXFileCodeGeneratorкак CustomTool
5. Щелкните правой кнопкой мыши Resources.resxи выберите «Запустить пользовательский инструмент». Это создаст новый файл designer.cs.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 решило проблему.

Я решил эту проблему, перейдя в проект, где был сохранен мой файл ресурсов, прокрутив вниз до его 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>

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

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

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

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

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

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

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

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

HttpContext.GetGlobalResourceObject()

Это сгенерирует эту ошибку, если мы не заключим этот вызов в оператор try / catch.

У меня есть приложение WinForms с одним проектом в решении.
Таргетинг .NET Framework 4.0
Использование в SharpDevelop 4.3качестве моей IDE

Звучит глупо, но мне удалось установить Logical Nameсвойство в "Resources"моем "Resources.resx"файле. После того как я очистил это имущество, все работает неуклюжий.

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

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

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

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

MyResource.cs
|_ MyResource.resx

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

MyResource.resx
|_ MyResource.cs

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

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

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

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

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

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

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

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

Просто еще один случай. Я скопировал решение с двумя проектами и переименовал их частично в проводнике Windows (имена папок, имена файлов .sln и .csproj) и частично с помощью массивного действия Find & Replace в Visual Studio (пространства имен и т. Д.). Тем не менее, исключение, установленное ФП, все же имело место Я узнал, что имена Assembly и Namespace были еще старыми.

Хотя проект и все остальное уже были названы OfficeStyleAssembly name и Default namespaceеще назвали Linckus .

После этого исправления все снова заработало нормально, скомпилируйте и запустите время :)

Для пользователей, сталкивающихся с этой проблемой в .NET Core 3.0, это может быть связано с серьезным изменением , внесенным в .NET Core 3.0, для разрешения которого просто установите EmbeddedResourceUseDependentUponConventionзначение false в вашем проекте csproj:

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

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

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

Вместе с Построение действия: Embedded Resourceи пользовательский инструмент: PublicResXFileCodeGenerator.

Свойства двойного щелчка в разделе приложения проверяют, совпадают ли имя сборки и пространство имен по умолчанию

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

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

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

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

Я столкнулся с этой проблемой при запуске команды миграции. Update-Databaseв консоли диспетчера пакетов.

Принятый ответ не решил мою проблему.

Мне пришлось изменить Build Action с Compileна, Embedded Resourceи это сработало для меня.

Вы можете сделать то же самое, используя следующие шаги:

1. Щелкните правой кнопкой мыши по миграции.
2. Измените свойство «Создать действие» «Скомпилировать» на «Встроенный ресурс»
3. Запустите команду Update-Database.

Щелкните правой кнопкой мыши по ресурсам и выберите Run Custom Tool

Это исправит дизайнер

Тот факт, что вы ссылаетесь на библиотеку DLL проекта B, не означает, что менеджер ресурсов проекта A знает о каталоге App_GlobalResources проекта B.

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