Localization and satellite assemblies, need help ASAP!

[Guest]

I am having some issues trying to figure out my localization/resource file
problems. Here is the scenario. I have a strongly typed resource file
called LocalizedStrings, and I use it during application startup (on an
Add-In-Express component, which ultimately extends the 'Component' base
class, not a WinForm) like this:

this.PageTitle = LocalizedStrings.AddinCore_PageTitle;
....etc.

This works fine, and if I create LocalizedStrings.fr-CA.resx, and do a build
within Visual Studio, set the UI culture to fr-CA, everything works great.

The problem arises when I try to add the fr-CA support outside of Visual
Studio using .NET tools. I need to test this way because this is how our
translators will do it. In any event, I follow the steps of doing a ResGen
to get the fr-CA.resx file, then generate the .resources file, then use the
Assembly Linker (al.exe) to ultimately generate the satellite assembly. This
generates a satellite DLL that appears to be the same as the one generated by
Visual Studio IDE, at least in size, but running the program still defaults
back to all of the en-US translations; for some reason it is not picking up
the satellite assembly, and I cannot figure out why. There are no exceptions
thrown or anything. Very frustrating.

Can someone recommend what I could be doing wrong, or a different way to try
and troubleshoot this problem, or some way to test whether my DLL produced by
the AL.exe is valid? I've tried generating with and without a key file as
well; neither way seems to work.

Any help would be greatly appreciated! Let me know if there is anything
else I can provide.

 

[Herfried K. Wagner [MVP]]

I am having some issues trying to figure out my localization/resource file
problems. Here is the scenario. I have a strongly typed resource file
called LocalizedStrings, and I use it during application startup (on an
Add-In-Express component, which ultimately extends the 'Component' base
class, not a WinForm) like this:

this.PageTitle = LocalizedStrings.AddinCore_PageTitle;
...etc.

This works fine, and if I create LocalizedStrings.fr-CA.resx, and do a
build
within Visual Studio, set the UI culture to fr-CA, everything works great.

The problem arises when I try to add the fr-CA support outside of Visual
Studio using .NET tools. I need to test this way because this is how our
translators will do it. In any event, I follow the steps of doing a
ResGen
to get the fr-CA.resx file, then generate the .resources file, then use
the
Assembly Linker (al.exe) to ultimately generate the satellite assembly.
This
generates a satellite DLL that appears to be the same as the one generated
by
Visual Studio IDE, at least in size, but running the program still
defaults
back to all of the en-US translations; for some reason it is not picking
up
the satellite assembly, and I cannot figure out why. There are no
exceptions
thrown or anything.

Maybe you are calling the assembly linker or another tool with wrong
parameters:

Komatineni, S.: .NET Localization, Part 2: Creating Satellite Assemblies
<URL:http://www.ondotnet.com/pub/a/dotnet/2002/10/14/local2.htm?page=1>

Kimmel, P.: Using Satellite Assemblies for Multi-Language Programming
<URL:http://www.codeguru.com/vb/gen/vb_misc/multi-languagesupport/article.php/c5601/>