Could not find any resources appropriate for the specified culture or the neutral culture

No-one seems to have mentioned this solution. Obvious really - but tripped me over for a moment...

The default access modifier for a new resources file is Internal (or Friend in VB.Net.) Make sure you change this to Public

(in the resx designer there is a dropdown at the top for the access modifier)

For users who facing this isssue in .NET Core 3.0, this could be related to a breaking change that made in .NET Core 3.0, to resolve it just set EmbeddedResourceUseDependentUponConvention to false in your project csproj:

<PropertyGroup>
  <EmbeddedResourceUseDependentUponConvention>true</EmbeddedResourceUseDependentUponConvention>
</PropertyGroup>

I resolved this by going to the project where my resources file was saved, scrolling down to its ItemGroup and adding a logical name that corresponded to the path the compiler expected.

My EmbeddedResource looked like this:

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

Now it looks like this

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

In my case, the issue caused by the wrong order of class definitions. For example, I had added another class definition before my Form class:

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

After moving BackendObject to the end of the file (better yet would be to move it to a separate file), doing project clean + rebuild resolved the issue.

One approach would be to put the shared classes/resources in a separate class library project and refer them in both the web sites.

Just another case. I copied a solution with two projects and renamed them partially in the Windows explorer (folder names, .sln and .csproj file names) and partially with a massive Find & Replace action in Visual Studio (namespaces etc.). Nevertheless the exception stated by the OP still occurred. I found out that the Assembly and Namespace names were still old.

Although the project and everything else was already named OfficeStyle the Assembly name and Default namespace were still named Linckus.

After this correction everything worked fine again, compile and run time :)

I faced this issue for running Migration command.Update-Database in Package Manager console.

Accepted answer didn't solve my problem.

I had to change Build Action from Compile to Embedded Resource and It worked for me.

You can do the same using below steps:

1. Right click on migration.
2. Change the "Build Action" property "Compile" to "Embedded Resource"
3. Run Update-Database command.

In my case I was trying to migrate a Form from one project to another. It turns out I only forget to add Form.resx to the new project. In the form I was using some icons so it was dependent to resources.

Yet another cause: if your namespace has a hyphen ("-"), then it will build and run correctly, but the resource won't be accessible. Namespaces (identifiers) aren't supposed to have hyphens, but this doesn't appear to be enforced anywhere except in loading resources. This has burned me twice over the decade.

Another thing to check is if you have LogicalName or ManifestResourceName defined on the EmbeddedResource. Make sure those are defined appropriately if your project file is using them as they can cause the resources to live under a name you are not expecting.

I had the same issue when trying to run an update-database command on EF. Turns out the migration that was throwing the exception had the .resx file excluded from the project. I just right-clicked the .resx file and clicked "Include In Project". Problem solved.

In my case, Build Action of the resource file was already Embedded Resource but every time I ran update-database, I got the same error, so i did the fellow steps and it's worked:

1. Change Build Action property to Compile
2. Build (got so many errors)
3. Change back Build Action property to Embedded Resource
4. update-database

And for some reason it's worked.

Had a similar issue for a NetCore project and I noticed that after I added my migration (let's name it WhateverMigration), the .resx file reference as EmbeddedResource was not added to the .csproj even tho everything seemed fine. So I opened my .csproj file and I added:

<EmbeddedResource Update="Migrations\202107071914322_WhateverMigration.resx">
    <Generator></Generator>
    <DependentUpon>202107071914322_WhateverMigration.cs</DependentUpon>
</EmbeddedResource>

You can also run into this exception when migrating a Windows Forms csproj to the new SDK-style project format. If you have any forms or user controls in subfolders, the *.resx files will generate using a namespace that includes the subfolder, which may not match the *.Designer.cs namespace. The solution is to add the following to the csproj:

<EmbeddedResourceUseDependentUponConvention>true</EmbeddedResourceUseDependentUponConvention>

None of the other answers solved it for me. I had moved a number of forms and controls from one assembly to another, fixed all the namespaces and raN into this issue.

To keep the moved controls and forms separate from the rest I had put them in a subfolder. One resource reference was updated as suggested in one of the other answers. The IDE was warning me about the file path not matching the namespace with a blue squiggly but that is not an error so I initially ignored it.

When nothing appreared to fix it for me and I did not know anything better to try anymore I finally moved the controls and forms out of their subfolder (which was not expressed in the namespace) and the problem was gone.

Apperently there is still some hard dependency in WinForms on the folder structure.

For me it was the following. In the MyStrings.Designer.cs file:

global::System.Resources.ResourceManager temp = 
    new global::System.Resources.ResourceManager(
      "MyApplication.MyProject", typeof(MyStrings).Assembly);

I had assumed that MyApplication.MyProject referred to the Namespace of the class rather than the directory of the file. I had placed the files in a subdirectory called Resources but the namespace didn't reflect that.

I changed it to

global::System.Resources.ResourceManager temp = 
    new global::System.Resources.ResourceManager(
      "MyApplication.MyProject.Resources", typeof(MyStrings).Assembly);

And it worked! (I didn't even have to update the namespace!)

Just because you are referencing Project B's DLL doesn't mean that the Resource Manager of Project A is aware of Project B's App_GlobalResources directory.

Are you using web site projects or web application projects? In the latter, Visual Studio should allow you to link source code files (not sure about the former, I've never used them). This is a little-know but useful feature, which is described here. That way, you can link the Project B resource files into Project A.