Nie można znaleźć żadnych zasobów odpowiednich dla określonej kultury lub kultury neutralnej

Mam dwa projekty sieciowe ASP.NET (ProjectA i ProjectB). Gdy klasa w ProjectA tworzy instancję klasy ProjectB, która korzysta z pliku zasobów Blah.resx, pojawia się ten błąd:

Wyjątek typu „System.Resources.MissingManifestResourceException” wystąpił w pliku mscorlib.dll, ale nie został obsłużony w kodzie użytkownika.

Nie można znaleźć żadnych zasobów odpowiednich dla określonej kultury lub kultury neutralnej. Upewnij się, że „Resources.Blah.resources” zostało poprawnie osadzone lub połączone w zestawie „App_GlobalResources.sn_flri6” w czasie kompilacji, lub że wszystkie wymagane zestawy satelitów są wczytywalne i w pełni podpisane.

Co to powoduje?

W witrynie firmy Microsoft znajduje się artykuł na temat tego http://support.microsoft.com/kb/318603, który sugeruje:

Aby rozwiązać ten problem, przenieś wszystkie pozostałe definicje klas, aby pojawiły się po definicji klasy formularza.

Jest to rozwiązanie dla projektu Windows Forms, nie jestem pewien, czy dotyczy to również projektów internetowych.

Właśnie trafiłem na ten sam wyjątek w projekcie WPF. Problem wystąpił w zestawie, który niedawno przenieśliśmy do innej przestrzeni nazw ( ProblemAssembly.Supportdo ProblemAssembly.Controls). Wystąpił wyjątek podczas próby uzyskania dostępu do zasobów z drugiego pliku zasobów, który istnieje w zestawie.

Okazuje się, że dodatkowy plik zasobów nie przeniósł poprawnie odniesień ze starej nazwy przestrzeni nazw do nowej nazwy przestrzeni nazw.

W pliku designer.cs dla pliku zasobów znajduje się właściwość statyczna umożliwiająca pobranie menedżera zasobów. W obrębie tego gettera ciąg nadal odwoływał się do starej przestrzeni nazw. Po poprawieniu go do nowej przestrzeni nazw problem został rozwiązany:

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

powinien był być:

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

Mam nadzieję, że to pomoże następnej osobie.

Rozwiązałem problem w ten sposób:

1. Kliknij prawym przyciskiem myszy plik ResourceFile
2. Zmień właściwość „Build Action” Compile na „Embedded Resource”
3. Następnie zbuduj i uruchom

Działa idealnie.

Kiedy próbowałem udostępnić plik resource.resx z jednego projektu C # z innym projektem C #, dostałem ten problem. Sugestia przeniesienia klasy Form na początek jej pliku była nieodpowiednia. Tak to rozwiązałem. Zasadniczo używasz łącza z drugiego projektu do pierwszego, a następnie włączasz regenerację resource.designer.cspliku.

1. Usuń Properties/Resources.resxplik drugiego projektu
2. Dodaj Properties/Resources.resxplik pierwszego projektu jako LINK do folderu Właściwości w drugim projekcie. Nie dodawaj go do poziomu głównego projektu.
3. Nie dodawaj pierwszego projektu Properties/Resources.designer.cs!
4. W właściwościach drugiego projektu Resources.resxdodaj ResXFileCodeGeneratorjako CustomTool
5. Kliknij prawym przyciskiem myszy Resources.resxi wybierz „Uruchom narzędzie niestandardowe”. Spowoduje to wygenerowanie nowego pliku designer.cs.

Uwaga: unikałbym edytowania pliku resource.designer.cs, ponieważ jest on generowany automatycznie.

W moim przypadku seria źle pomyślanych globalnych zamienników tekstu nieumyślnie zmieniła ten wiersz w pliku cs projektanta zasobów.

Ponieważ przestrzeń nazw w tym argumencie nie była już zgodna z przestrzenią nazw klasy, aplikacja uległa dezorientacji w czasie wykonywania.

Sprawdź, czy przestrzeń nazw projektanta jest zgodna z argumentem ciągu w tym wierszu.

Dzieje się tak, ponieważ *.resхwykluczone z migracji.

• Kliknij prawym przyciskiem myszy plik ResourceFile
• Kliknij pozycję menu „Uwzględnij w projekcie”

Odkryłem, że usunięcie pliku designer.cs, z wyłączeniem pliku resx z projektu, a następnie ponowne włączenie go często rozwiązało ten problem, po refaktoryzacji przestrzeni nazw (zgodnie z odpowiedzią CFinck)

Wydaje się, że nikt nie wspomniał o tym rozwiązaniu. Oczywiste, naprawdę - ale potknąłem się na chwilę ...

Domyślny modyfikator dostępu dla nowego pliku zasobów to Internal(lub Friendw VB.Net.) Upewnij się, że zmieniłeś to naPublic

(w projektancie resx znajduje się menu rozwijane u góry dla modyfikatora dostępu)

Sama odpowiedź Sibi Elangos nie była dla mnie wystarczająca, więc musiałem

• Kliknij prawym przyciskiem myszy plik ResourceFile
• Zmień właściwość „Build Action”
• Kompiluj do „Osadzonego zasobu”
• Kompiluj i wdrażaj

Spowoduje to wygenerowanie App_GlobalResources w twoim /binfolderze, teraz skopiuj ten folder również do katalogu głównego aplikacji internetowej

W moim przypadku problem spowodowany niewłaściwym zdefiniowaniem klasy:

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

Po ponownym przydzieleniu BackendObjectdo końca (lepiej oddzielić plik), wykonanie projektu czystego + przebudowanie rozwiązało problem.

Rozwiązałem ten problem, przechodząc do projektu, w którym został zapisany mój plik zasobów, przewijając w dół do jego grupy przedmiotów i dodając logiczną nazwę odpowiadającą ścieżce oczekiwanej przez kompilator.

Mój EmbeddedResource wyglądał tak:

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

Teraz wygląda to tak

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

W tym przypadku sprawdź, czy zestaw zawierający zasoby ma domyślną przestrzeń nazw ustawioną na ten sam tekst (Projekt-> Właściwości-> Domyślna przestrzeń nazw; w VS) Sprawdź również, czy plik resx ma właściwość BuildAction ustawioną na „Osadzony” zasób „Ciesz się ...;)

Jednym z podejść byłoby umieszczenie wspólnych klas / zasobów w osobnym projekcie biblioteki klas i skierowanie ich na obie strony internetowe.

Dzięki @CFinck! Aby dodać wskazówkę do innych: zmieniłem linię ResourceManager w ten sposób:

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

Jestem w vb.net, ale myślę, że w C # jedyną różnicą byłoby + zamiast & by połączyć łańcuchy.

W ten sposób mogę używać tych samych połączonych plików zespołów w dwóch podobnych projektach, które współużytkują zasoby.

Ten błąd jest również zgłaszany przez Dotfuscation, ponieważ plik projektanta resx opiera się na odbiciu. Jeśli używasz Dotfuscatora, spowoduje to uszkodzenie plików resx. Zawsze musisz dodać je jako wykluczenie z procesu zaciemniania.

Kiedy korzystaliśmy

HttpContext.GetGlobalResourceObject()

Generowałby ten błąd, chyba że zawiniemy to wywołanie w instrukcji try / catch.

Mam aplikację WinForms z jednym projektem w rozwiązaniu.
Kierowanie .NET Framework 4.0
Korzystanie SharpDevelop 4.3jak moja IDE

Brzmi głupio, ale zdarzyło mi się mieć Logical Namewłaściwość ustawioną "Resources"w moim "Resources.resx"pliku. Po wyczyszczeniu tej nieruchomości wszystko działa jak przystojniak.

Zwykle, gdy dodajesz losowe pliki jako EmbeddedResource, zazwyczaj chcesz ustawić Logical Namecoś rozsądnego, z jakiegoś powodu zrobiłem to samo dla Resources.resxpliku i to wszystko spieprzyło ...

Mam nadzieję, że to komuś pomoże.

Dla mnie problemem było kopiowanie plików .resx i powiązanych plików .cs z jednego projektu do drugiego. Oba projekty miały tę samą przestrzeń nazw, więc to nie był problem.

Wreszcie rozwiązałem problem, gdy zauważyłem w Solution Explorer, że w oryginalnym projekcie pliki .resx były zależne od plików .cs:

MyResource.cs
|_ MyResource.resx

W skopiowanym projekcie pliki .cs były zależne od plików .resx:

MyResource.resx
|_ MyResource.cs

Okazało się, że w drugim projekcie w jakiś sposób pliki .resx zostały ustawione na automatyczne generowanie plików .cs. Automatycznie wygenerowane pliki .cs zastępowały pliki .cs skopiowane z oryginalnego projektu.

Aby rozwiązać problem, edytuj właściwości każdego pliku .resx w skopiowanym projekcie. Właściwość Custom Tool zostanie ustawiona na coś takiego jak ResXFileCodeGenerator . Wyczyść właściwość Custom Tool pliku .resx. Konieczne będzie ponowne skopiowanie pliku .cs z oryginalnego projektu, ponieważ zostanie on zastąpiony automatycznie wygenerowanym plikiem.

W moim przypadku umieściłem nową klasę na formularzu Windows w tym samym pliku.

Usunięcie nowo dodanej klasy z tego pliku rozwiązało problem.

Zobacz tutaj: http://i.stack.imgur.com/wVu6c.png

Może to być spowodowane niedopasowanymi przestrzeniami nazw. Druga odpowiedź od góry (Sibi Elango) mówi, aby kliknąć prawym przyciskiem myszy plik resx i zmienić opcję kompilacji na EmbeddedResource, ale już to zrobiłem i nadal miałem błąd. Najlepsza odpowiedź (CFinck's) wskazuje na sposób naprawienia tego poprzez ręczną edycję plików, miałem jednak ten problem w MonoDevelop i musiałem ustawić domyślną przestrzeń nazw na taką samą jak plik cs, który wzywał do zasobu (plik, który zawierał kod, taki jak kod poniżej) ...

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

Po ustawieniu domyślnej przestrzeni nazw za pomocą GUI powyższy wiersz nie powodował już wyjątku.

Po prostu inna sprawa. Skopiowałem rozwiązanie z dwoma projektami i nazwałem je częściowo w Eksploratorze Windows (nazwy folderów, nazwy plików .sln i .csproj), a częściowo za pomocą ogromnej akcji Znajdź i zamień w Visual Studio (przestrzenie nazw itp.). Niemniej jednak wyjątek określony przez PO nadal występował. Dowiedziałem się, że nazwy Zgromadzenia i Przestrzeni Nazw były wciąż stare.

Chociaż projekt i wszystko inne zostało już nazwane OfficeStyleAssembly name i Default namespacewciąż nazwany Linckus .

Po tej korekcie wszystko znów działało dobrze, skompiluj i uruchom :)

W moim przypadku te wiersze kodu bardzo mi Web.configpomogły:

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

Wraz z działaniem produkcji: Embedded Resourcei niestandardowe narzędzia: PublicResXFileCodeGenerator.

Właściwości podwójnego kliknięcia w sekcji Aplikacja sprawdź Nazwa zestawu i domyślna przestrzeń nazw są takie same

Miałem również do czynienia z tym samym problemem, wypróbowałem wszystkie rozwiązania wymienione w odpowiedzi, ale żadne nie wydawało się działać. Okazało się, że podczas odprawy kodu do TFS. TFS nie rejestrował pliku Resx, tylko sprawdzał w pliku projektanta. Tak więc wszyscy inni programiści mieli do czynienia z tym problemem podczas pracy na swoich komputerach. Ręczne sprawdzenie pliku resx załatwiło sprawę

Może się to również zdarzyć, gdy umieścisz klasę nad główną klasą winform (na przykład Form1). Możesz to zobaczyć, patrząc na projekt, ponieważ nie jest on renderowany.

Jeszcze jedna przyczyna: jeśli twoja przestrzeń nazw zawiera myślnik („-”), to zbuduje się i uruchomi poprawnie, ale zasób nie będzie dostępny. Przestrzenie nazw (identyfikatory) nie powinny mieć łączników, ale wydaje się, że nie jest to egzekwowane nigdzie poza ładowaniem zasobów. Spaliło mnie to dwukrotnie w ciągu dekady.

Inną sprawą do sprawdzenia jest to, czy w EmbeddedResource zdefiniowano LogicalName lub ManifestResourceName. Upewnij się, że są one odpowiednio zdefiniowane, jeśli plik projektu ich używa, ponieważ mogą spowodować, że zasoby będą działały pod nazwą, której się nie spodziewasz.

Napotkałem ten problem podczas uruchamiania polecenia migracji. Update-Databasew konsoli Menedżera pakietów.

Zaakceptowana odpowiedź nie rozwiązała mojego problemu.

Musiałem zmienić Build Action z Compilena Embedded Resourcei to zadziałało dla mnie.

Możesz zrobić to samo, wykonując poniższe czynności:

1. Kliknij migrację prawym przyciskiem myszy.
2. Zmień właściwość „Build Action” „Compile” na „Embedded Resource”
3. Uruchom polecenie Update-Database.

Dla użytkowników, którzy napotykają ten problem w .NET Core 3.0, może to być związane z przełomową zmianą, która dokonała się w .NET Core 3.0, aby rozwiązać ten problem, po prostu ustaw EmbeddedResourceUseDependentUponConventionna false w swoim projekcie csproj:

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

Kliknij zasoby prawym przyciskiem myszy i wybierz Run Custom Tool

To naprawi projektanta

To, że odwołujesz się do biblioteki DLL projektu B, nie oznacza, że ​​Menedżer zasobów projektu A zna katalog App_GlobalResources projektu B.

Czy korzystasz z projektów witryn internetowych lub projektów aplikacji internetowych? W drugim przypadku program Visual Studio powinien umożliwiać łączenie plików kodu źródłowego (nie jestem pewien co do tego pierwszego, nigdy ich nie użyłem). Jest to mało znana, ale przydatna funkcja, którą opisano tutaj . W ten sposób możesz połączyć pliki zasobów Projektu B z Projektem A.