none
Resource String - Could not find file RRS feed

  • Question

  • Gentlemen,

     

    We need your help: we have a large application, composed by several assemblies. These assemblies' localization is based on resource dlls. For our neutral culture, the resource strings are embedded in the very own dlls. Whenever we want to translate the application, we generate the specific resource files. This approach has always worked fine.

     

    A few days ago, we started having problems resolving these assemblies in the default language. Our AssemblyResolve event returns null, since the resource strings are embedded inside the dll. Normally, the application would simply fall back and search the string inside the origin dll. However, what we see is an exception in the InternalGetSatelliteAssembly method, as follows:

     

     

    Could not find file 'RM.Fop.Calc.Calculos.resources'.

    StackTrace: 

     

       at System.Reflection.RuntimeAssembly.InternalGetSatelliteAssembly(String name, CultureInfo culture, Version version, Boolean throwOnFileNotFound, StackCrawlMark& stackMark)

       at System.Resources.ManifestBasedResourceGroveler.GetSatelliteAssembly(CultureInfo lookForCulture, StackCrawlMark& stackMark)

       at System.Resources.ManifestBasedResourceGroveler.GrovelForResourceSet(CultureInfo culture, Dictionary`2 localResourceSets, Boolean tryParents, Boolean createIfNotExists, StackCrawlMark& stackMark)

       at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo requestedCulture, Boolean createIfNotExists, Boolean tryParents, StackCrawlMark& stackMark)

       at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tryParents)

       at System.Resources.ResourceManager.GetString(String name, CultureInfo culture)

       at RM.Fop.Calculos.Properties.Resources.get_SFopFaltasEstornadasNoMes()

       at RM.Fop.Calculos.Funcionario.VerificaFaltasCC8(List`1& avosPerdidos, Decimal& dias, Int32 mesIni, Int32 anoIni, Int32 mesFim, Int32 anoFim, String ferias13, Boolean excluiEnvCorrente, Boolean escreveLog)

     

     

    It does not look like an application issue, since it works in most of the environments, and it does not in some others. We think it has something to do with the .NET version installed, or maybe the Windows version. We had a similar issue with Windows 2008 R2 before. Maybe that's a way to start. We are also debbuging the InternalGetSatelliteAssembly, lets see what we find.

     

    Please guys, lets talk. If you have any questions just ask, I will answer it right away.

     

    Tks,

    Rafael Neves


    Regards, Rafael Neves
    Monday, July 25, 2011 3:30 AM

Answers

  • Try replacing the wrong-going DLL with new ones. Copy the good working and replace the text to other language.
    • Proposed as answer by Jacob Brown Monday, July 25, 2011 7:13 PM
    • Marked as answer by Paul Zhou Tuesday, August 2, 2011 7:21 AM
    Monday, July 25, 2011 6:25 PM

All replies

  • Gentlemen,

     

    We need your help: we have a large application, composed by several assemblies. These assemblies' localization is based on resource dlls. For our neutral culture, the resource strings are embedded in the very own dlls. Whenever we want to translate the application, we generate the specific resource files. This approach has always worked fine.

     

    A few days ago, we started having problems resolving these assemblies in the default language. Our AssemblyResolve event returns null, since the resource strings are embedded inside the dll. Normally, the application would simply fall back and search the string inside the origin dll. However, what we see is an exception in the InternalGetSatelliteAssembly method, as follows:

     

     

    Could not find file 'RM.Fop.Calc.Calculos.resources'.

    StackTrace: 

     

       at System.Reflection.RuntimeAssembly.InternalGetSatelliteAssembly(String name, CultureInfo culture, Version version, Boolean throwOnFileNotFound, StackCrawlMark& stackMark)

       at System.Resources.ManifestBasedResourceGroveler.GetSatelliteAssembly(CultureInfo lookForCulture, StackCrawlMark& stackMark)

       at System.Resources.ManifestBasedResourceGroveler.GrovelForResourceSet(CultureInfo culture, Dictionary`2 localResourceSets, Boolean tryParents, Boolean createIfNotExists, StackCrawlMark& stackMark)

       at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo requestedCulture, Boolean createIfNotExists, Boolean tryParents, StackCrawlMark& stackMark)

       at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tryParents)

       at System.Resources.ResourceManager.GetString(String name, CultureInfo culture)

       at RM.Fop.Calculos.Properties.Resources.get_SFopFaltasEstornadasNoMes()

       at RM.Fop.Calculos.Funcionario.VerificaFaltasCC8(List`1& avosPerdidos, Decimal& dias, Int32 mesIni, Int32 anoIni, Int32 mesFim, Int32 anoFim, String ferias13, Boolean excluiEnvCorrente, Boolean escreveLog)

     

     

    It does not look like an application issue, since it works in most of the environments, and it does not in some others. We think it has something to do with the .NET version installed, or maybe the Windows version. We had a similar issue with Windows 2008 R2 before. Maybe that's a way to start. We are also debbuging the InternalGetSatelliteAssembly, lets see what we find.

     

    Please guys, lets talk. If you have any questions just ask, I will answer it right away.

     

    Tks,

    Rafael Neves


    Regards, Rafael Neves

    When You are writing a localization DLL you have to embed two things: the content of that DLL (I mean programming content: classes, namespaceses...) and also the reources page (found in Project Properties > Resources). 

    if RM.Fop.Calc.Calculos is Your project namespace (all Your programmings are placed here), than RM.Fop.Calc.Calculos.resources is the resource file for that namespace.

    Maybe when You were creating a specific translation, You changed a namespace. I'm not sure, but it can also be caused be changing the Default namespace (My Project > properties)

    • Proposed as answer by Jacob Brown Monday, July 25, 2011 7:13 PM
    Monday, July 25, 2011 5:04 PM
  • Thanks Jacob. I am aware of that. I checked it out and the namespace is fine.

     

    During the morning I found out that this issue happens when the server Regional Settings is set to a culture different from the default one. In this case, our neutral language is portuguese (pt-BR) and the Windows Server is set to english (en-US). When we set the machine's culture to portuguese, in order to match the app, the application runs as expected. Since the application works fine with the machine configured to portuguese, I think we can discard namespace mistakes.

     

    Changing the regional settings make the application available again, but it does not explain why the error occurred on the first hand. As far as my knowledge goes, if the app is running in other language and it can't find the resource dll, it should fallback to the default one. In fact, that's what it used to do on previous versions.

     

    What do you think?


    Regards, Rafael Neves
    • Proposed as answer by Jacob Brown Monday, July 25, 2011 7:14 PM
    Monday, July 25, 2011 5:30 PM
  • Do You have you app localized for default language?

    • Proposed as answer by Jacob Brown Monday, July 25, 2011 7:13 PM
    Monday, July 25, 2011 5:55 PM
  • I don't know if I understand your question.

     

    We have the default resource.resx files in the solution, where we add all of our strings, but we do not generate resource.dll assemblies for them. For the default language, the resources remain embedded inside the main dll. We generate the resource.dll files only if we want to translate to other languages.

     

    Is that what you asked?


    Regards, Rafael Neves
    • Proposed as answer by Jacob Brown Monday, July 25, 2011 7:13 PM
    Monday, July 25, 2011 6:09 PM
  • Never mind.
    • Proposed as answer by Jacob Brown Monday, July 25, 2011 7:13 PM
    Monday, July 25, 2011 6:24 PM
  • Try replacing the wrong-going DLL with new ones. Copy the good working and replace the text to other language.
    • Proposed as answer by Jacob Brown Monday, July 25, 2011 7:13 PM
    • Marked as answer by Paul Zhou Tuesday, August 2, 2011 7:21 AM
    Monday, July 25, 2011 6:25 PM
  • Yes, if I don't find the cause, that might work.

    Thanks!


    Regards, Rafael Neves
    • Proposed as answer by Jacob Brown Monday, July 25, 2011 7:13 PM
    • Unproposed as answer by Rafael Neves Monday, July 25, 2011 7:19 PM
    Monday, July 25, 2011 6:34 PM