Resource files with multiple languages

I got a server app in which I want to have support for multiple languages using resource files. Since it's a server, I can't use satellite assemblies (since different threads uses different languages).

I've tried to 开发者_开发知识库add multiple resource files in the following way:

• MyResourceName.resx
• MyResourceName.sv.resx

They contain one string table with one text in them.

I used Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo(1053); to switch language. But i still got the default language when using var string = MyResourceName.MyText.

Ive tried to change the CurrentUICulture too.

How do I add support for multiple languages?

Update

Don't know if it matters. But I'm trying from within my unit test project (mstest). The resource files are also a part of the test project.

---

First, it is CurrentUICulture that controls this (I noticed that you tried that too; just wanted to clarify it).

Second: is the application multi-threaded? Could it be that you set CurrentUICulture on one thread, but read MyResourceName.Text on another (which then is not having the same culture)?

---

If you have a ResourceManager like this

var manager = new ResourceManager("you.resource.strings.file", Assembly.GetExecutingAssembly());

you can always get a string from it with in the desired language by calling the overloaded GetString method that takes a CultureInfo object as a parameter. In that way you don't have to set the Culture on your thread.

var string = manager.GetString("myText", CultureInfo.GetCulture(1053));

---

If the .RESX are defined with an "Embedded Resource" Build Action in Visual Studio (with a Custom Tool set to "ResXFileCodeGenerator"), you have to deploy the .resources.dll compiled for swedish. It should be in the bin\sv folder.

For ASP.NET webapps, if you define the .RESX files in a folder called App_GlobalResources, then you will not have a bin\sv folder (in this case the Build Action will we "Content" with a Custom Tool set to "GlobalResourceProxyGenerator"), so as you say, you don't have to deploy an extra dll.

In both cases the code is fine (with CurrentUICulture, not CurrentCulture) and should work.