Не вдалося знайти жодних ресурсів, відповідних зазначеній культурі чи нейтральній культурі

У мене є два веб-проекти ASP.NET (ProjectA і ProjectB). Коли клас у ProjectA створює екземпляр класу ProjectB, який використовує файл ресурсу Blah.resx, я отримую цю помилку:

Виняток типу "System.Resources.MissingManifestResourceException" стався в mscorlib.dll, але не використовувався в коді користувача.

Не вдалося знайти жодних ресурсів, відповідних зазначеній культурі чи нейтральній культурі. Переконайтесь, що "Resources.Blah.resources" було правильно вбудовано або пов’язано у збірку "App_GlobalResources.sn_flri6" під час компіляції, чи всі супутникові збори потрібні для завантаження та повністю підписані.

Що це спричиняє?

На сайті Майкрософт є стаття про цю http://support.microsoft.com/kb/318603, яка пропонує:

Щоб вирішити цю проблему, перемістіть усі інші визначення класів так, щоб вони з'явилися після визначення класу форми.

Це рішення для проекту Windows Forms, я не впевнений, чи це стосується і веб-проектів.

Я просто потрапив на цей самий виняток у проекті WPF. Проблема виникла в рамках збірки, яку ми нещодавно перенесли в іншу область імен ( ProblemAssembly.Supportдо ProblemAssembly.Controls). Виняток стався під час спроби доступу до ресурсів із другого файлу ресурсів, який існує у збірці.

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

У дизайнері.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. Змініть властивість "Зробити дію" Компілюйте на "Вбудований ресурс"
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та виберіть "Запустити спеціальний інструмент". Це створить новий файл дизайнера.cs.

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

У моєму випадку серія погано продуманих глобальних замін тексту ненароком змінила цей рядок у файлі CS-дизайнера ресурсу.

Оскільки простір імен у цьому аргументі більше не збігався з простором імен класу, програма заплуталася під час виконання.

Переконайтеся, що простір імен дизайнера відповідає аргументу рядків у цьому рядку.

Це відбувається тому, що *.resхвиключається з міграції.

• Клацніть правою кнопкою миші на файлі ResourceFile
• Клацніть на пункт меню "Включити у проект"

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

Здається, ніхто не згадував про це рішення. Очевидно насправді - але на мить сполохав мене ...

Модифікатором доступу для нового файлу ресурсів за замовчуванням є Internal(або Friendу VB.Net.) Переконайтеся, що ви змінили це наPublic

(у дизайнера resx є спадне меню вгорі для модифікатора доступу)

Сама відповідь Сібі Елангос для мене була недостатньою, тому мені довелося

• Клацніть правою кнопкою миші на файлі ResourceFile
• Змініть властивість "Зробити дію"
• Компілювати до "Вбудованого ресурсу"
• Побудувати та розгорнути

Це створить 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до кінця (краще відокремити файл), виконавши проект чистим + відновити вирішено проблему.

Я вирішив це, перейшовши до проекту, де був збережений мій файл ресурсів, прокрутившись до його 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()

Це призведе до помилки, якщо ми не загорнемо цей виклик всередині оператора спробувати.

У мене є додаток 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 . Очистіть властивість користувальницького інструменту файлу .resx. Вам потрібно буде скопіювати файл .cs з оригінального проекту, оскільки він буде перезаписаний автоматично створеним файлом.

У моєму випадку я розмістив новий клас поверх форми Windows у тому ж файлі.

Виведення проблеми із доданого класу із цього файлу виправлено проблему.

Дивіться тут: http://i.stack.imgur.com/wVu6c.png

Це може бути викликано невідповідними просторами імен. Другий з верхньої відповіді (Сібі Еланго) говорить, що клацніть правою кнопкою миші файл resx та змініть параметр Build на EmbeddedResource, але я вже це зробив і все-таки помилка. У верхній відповіді (CFinck's) відзначається спосіб виправити це за допомогою редагування файлів вручну, однак у мене була проблема в MonoDevelop, і мені довелося встановити простір імен за замовчуванням таким самим, як файл CS, який викликав ресурс (файл, який міститься такий код, як код нижче) ...

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

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

Просто інший випадок. Я скопіював рішення з двома проектами і частково перейменував їх у Провідник Windows (назви папок, назви файлів .sln та .csproj), а частково - з масовою дією Find & Replace у Visual Studio (простори імен тощо). Проте виняток, заявлений ОП, все ж стався. Я дізнався, що назви Асамблеї та простору імен ще були старими.

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

Після цього виправлення все знову працювало нормально, компілюйте та запускайте час :)

У моєму випадку ці рядки коду додали, що Web.configдопомогло чимало:

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

Разом з Побудова дії: Embedded Resourceі призначений для користувача інструмент: PublicResXFileCodeGenerator.

Властивості подвійного клацання в розділі програми перевірте ім'я складання та простір імен за замовчуванням однакові

Я також зіткнувся з тим же питанням, спробував усі рішення, згадані у відповіді, але жодне, здавалося, не спрацювало. Виявилося, що під час реєстрації коду до TFS. TFS не перевірив файл Resx, він лише перевірив у файлі дизайнера. Тому всі інші розробники стикалися з цим питанням під час роботи на своїх машинах. Перевірка файлу resx вручну зробила трюк

Це також може статися, коли кладемо клас над основним класом winform (наприклад, Form1). Це можна побачити, дивлячись на конструкцію, оскільки вона не може бути надана.

Ще одна причина: якщо у вашому просторі імен є дефіс ("-"), він буде побудований і запускається правильно, але ресурс не буде доступним. У просторах імен (ідентифікаторів) не повинно бути дефісів, але це, здається, не застосовується ніде, крім завантаження ресурсів. Це спалювало мене двічі за десятиліття.

Інша річ, щоб перевірити, чи є у вас вбудовані LogicalName або ManifestResourceName в EmbeddedResource. Переконайтеся, що вони визначені належним чином, якщо ваш проект проекту використовує їх, оскільки вони можуть спричинити, що ресурси живуть під іменем, якого ви не очікуєте.

Я зіткнувся з цим питанням для запуску команди Migration. Update-Databaseв консолі диспетчера пакунків.

Прийнята відповідь не вирішила моєї проблеми.

Мені довелося змінити Build Action з Compileна, Embedded Resourceі це працювало на мене.

Ви можете зробити те ж саме, виконавши наведені нижче дії.

1. Клацніть правою кнопкою миші на міграції.
2. Змініть властивість "Зробити дію" "Компілювати" на "Вбудований ресурс"
3. Запустіть команду Update-Database.

Для користувачів, які стикаються з цією проблемою в .NET Core 3.0, це може бути пов’язано з переломною зміною, яка була внесена в .NET Core 3.0, щоб вирішити її просто встановленою EmbeddedResourceUseDependentUponConventionна помилку в проекті csproj:

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

Клацніть правою кнопкою миші на ресурсах і виберіть Run Custom Tool

Це виправить дизайнер

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

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