Satellite assembly is not picked up by ASP.NET app

Question

I have a web project called "TestResourceApp" with Labels.resx in App_GlobalResources folder. I want to add another language by creating a satellite assembly.

Here are the steps I took to create the satellite assembly. The default text always get displayed. What did I do wrong ?

1) Create Labels.fr.resx in a different folder.

2) Generate resource file:

Resgen Labels.fr.resx TestResourceApp.App_GlobalResources.Labels.fr.resources

3) Generate satellite assembly:

AL /t:lib /embed:TestResourceApp.App_GlobalResources.Labels.fr.resources /out:french.dll /c:fr

4) Copy french.dll to TestResourceApp/bin/fr

I have uiculture set to auto in web.config and I have change the language on the browser.

Answer 1

It's complicated but here are a few tips for those who run into this problem:

• Try to include the resx in the web project and let VS do the job for you.
• Reflector is your friend. Compare satellite assemblies you created and those created by VS.
• If you web app is targetting ASP.NET 2.0, you should use Resgex and AL that come with .net 2.0. Open the assemblies in Reflector and check the "references". It should reference mscorlib version 2.0.
• If you deploy your web app using web deployment project, make sure the namespace for the resources in your satellite assemblies is correct. Again, compare with what VS creates. In my case, I used the wrong tool to generate the designer.cs file because I wanted them to be accessible from a different assembly. Make sure you are using GlobalResourceProxyGenerator. Otherwise, the namespaces won't match and the deployment code will not be able to find your resource. The namespace in the designer.cs should simply be "Resources", not "XXXX.App_GlobalResources"

Answer 2

Did you have set enableClientBasedCulture to true in globalization ?

Answer 3

I was able to use this page to solve some satellite assembly issues I was having. I'll throw in a few more things to check.

It's helpful to decompile the "neutral" assembly and see how it's put together. A tool like ILDASM.exe is helpful for this purpose. Once you get it decompiled, look through the text output for ".mresource", and you should see one with your naming. For example, if you add a resource to a Visual Studio project, they're named MyAssemblyName + ".Properties.Resources" + a language (if any) + ".resources" Examples:

MyAssembly.Properties.Resources.resources (neutral language) MyAssembly.Properties.Resources.en-US.resources (English (US))

In my case, I had the file named properly, and in the appropriate folder (such as Bin\en-US). I was able to verify that much by using ProcMon.exe (by the SysInternals guys) and could see the worker process finding and reading in my DLL file (instead of just saying "PATH NOT FOUND"). However, it was not finding the resource by the name that it expected it to. That's when some disassembly helped to get to the bottom of the naming problem.

So, use ProcMon.exe to narrow down the kind of problem you might have. Hopefully that's helpful to someone.