By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,187 Members | 1,041 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,187 IT Pros & Developers. It's quick & easy.

Globalization of ASP.NET applications problem

P: n/a
I'm hoping someone here can help with this one as I've
been looking all around for a solution to this and I've
yet to find one that is satisfactory.

I'm trying to add support for different languages to my
ASP.NET project. I have read the docs in MSDN and several
sites and newsgrops but still can't get this working as
advertized.

I have created string resources in both a .txt and a .resx
and get the same results with both. I have tried using
VS.NET to compile the satellite assemblies for me and I
have built them myself.

I have the following problems:
When I let VS.NET build my .resx files by adding them to
the project, it correctly creates the satellite assemblies
and places them in bin/en-GB/appname.resource.dll and
thats fine. However when I use ildasm to look at the dll I
see that the name of the resource section is the fully
qualified namespace of my app with the culture on the end.
I have no problem with using the full app name but the
culture should not be there from what I've seen since I
have to specify this name on the constructor to
ResourceManager and I want multiple cultures. This means
given that I have a resx called strings.en-GB.resx and
assuming a namespace of Namespace.Something.App I have to
create a resource manager like this:

new ResourceManager("Namespace.Something.App.strings.e n-
GB")

which is not good. I can get around this problem by
manually building using resgen and al but from what I see
this should work without the en-GB on the end.

The second, and probably more major problem since I cannot
get around it, is that when I write code that matches all
of the examples it looks like the satellite assemblies are
not being found.

Assembly a = Assembly.GetExecutingAssembly();
ResourceManager rm = new ResourceManager("myapp", a);
errorMsg.Text = rm.GetString("PAGE_ERROR");

I've checked that the current UI and thread culture is en-
GB but nothing is being retrieved from the en-GB
satellite. Its as though it cannot be found and it falls
back to culture neutral.

When I try this explicitly setting the satellite it works
fine eg.

Assembly a = Assembly.GetExecutingAssembly
().GetSatelliteAssembly(CultureInfo.CurrentUICultu re);

Its as though the resource manager is not looking up the
satellite assembly. Obviously I don't want to have to use
code like the above since I'd have to have different
resource managers for each culture which sort of defeats
the point. I've been over this so many times now, I must
be missing something obvious but I can't see what it is.

Hopefully someone can help me with one or both of these
problems. Preferably the latter if they can but both would
be nice.

Thanks

Rob Garfoot
Nov 18 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Ok I've got this working now, I have absolutely no idea
what I did but it works.
-----Original Message-----
I'm hoping someone here can help with this one as I've
been looking all around for a solution to this and I've
yet to find one that is satisfactory.

I'm trying to add support for different languages to my
ASP.NET project. I have read the docs in MSDN and several
sites and newsgrops but still can't get this working as
advertized.

I have created string resources in both a .txt and a .resxand get the same results with both. I have tried using
VS.NET to compile the satellite assemblies for me and I
have built them myself.

I have the following problems:
When I let VS.NET build my .resx files by adding them to
the project, it correctly creates the satellite assembliesand places them in bin/en-GB/appname.resource.dll and
thats fine. However when I use ildasm to look at the dll Isee that the name of the resource section is the fully
qualified namespace of my app with the culture on the end.I have no problem with using the full app name but the
culture should not be there from what I've seen since I
have to specify this name on the constructor to
ResourceManager and I want multiple cultures. This means
given that I have a resx called strings.en-GB.resx and
assuming a namespace of Namespace.Something.App I have to
create a resource manager like this:

new ResourceManager("Namespace.Something.App.strings.e n-
GB")

which is not good. I can get around this problem by
manually building using resgen and al but from what I see
this should work without the en-GB on the end.

The second, and probably more major problem since I cannotget around it, is that when I write code that matches all
of the examples it looks like the satellite assemblies arenot being found.

Assembly a = Assembly.GetExecutingAssembly();
ResourceManager rm = new ResourceManager("myapp", a);
errorMsg.Text = rm.GetString("PAGE_ERROR");

I've checked that the current UI and thread culture is en-
GB but nothing is being retrieved from the en-GB
satellite. Its as though it cannot be found and it falls
back to culture neutral.

When I try this explicitly setting the satellite it works
fine eg.

Assembly a = Assembly.GetExecutingAssembly
().GetSatelliteAssembly(CultureInfo.CurrentUICult ure);

Its as though the resource manager is not looking up the
satellite assembly. Obviously I don't want to have to use
code like the above since I'd have to have different
resource managers for each culture which sort of defeats
the point. I've been over this so many times now, I must
be missing something obvious but I can't see what it is.

Hopefully someone can help me with one or both of these
problems. Preferably the latter if they can but both wouldbe nice.

Thanks

Rob Garfoot
.

Nov 18 '05 #2

P: n/a
On Fri, 21 Nov 2003 02:22:19 -0800 Rob Garfoot wrote:
Rob Garfoot wrote:
Ok I've got this working now, I have absolutely no idea
what I did but it works.


Does it work on another server than the one you are developing on?
Michael
Nov 18 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.