ResourceManager strange behavior

[Mircea Pleteriu]

Hi,

I've created a test aspnet web application which contains one page only.
There is only one label control placed on the page.

The text of the label control is set on server side by the PageLoad method.
The text is stored into a sattelite assembly.

This is the code which sets the text:

CultureInfo ci = new CultureInfo("de-DE");

Thread.CurrentThread.CurrentCulture = ci;

Thread.CurrentThread.CurrentUICulture = ci;

ResourceManager rm = new ResourceManager("WebApplication6.Resources",
Assembly.GetExecutingAssembly());

this.Label1.Text = rm.GetString("test");

Running the app the German text is set as expected.

Now.. the strange behavior.

If I add the element

<identity impersonate="true"/>

to the config file the resource manager fails loading the corrext text. The
german text is not found anymore and the text for the default language is
loaded.

Do you know why it happens? Is there anything I miss?

 

[Steven Cheng[MSFT]]

Hi Mircea,

Welcome to ASPNET newsgroup.
As for the accessing localized resource in satellite assembly problem you
mentioned, it is a well-known issue which is indeed caused by the
impersonation. The reason only default culture's resouce is loaded and
other specific cultures' can't be loaded is as below:

Loading the resource in satelitte dll will cause them to be shadow copied
to the temporary asp.net files folder. This will be done using the
Impersonation token if impersonation is being used. If not, then it will
use the process identity. Usually, the error is caused by the impersonated
identity not having permissions to write to the Temporary ASP.NET files
folder.

So as for your scenario, it seems the client user which is impersonated
didn't have the proper permission. There're two options:
1. Turn off imperonate and using the process identity to run asp.net , by
default is NetworkService account which will have the sufficient pemission
to access ASPNET temporary folder.

2. Granting the impersonated account the sufficient permission to the
temporary asp.net folder. I don't think this is a good idea since you may
have multi-client users in your app and it's hard to ensure that all those
accounts have the proper access control over the temp dir. Also, in
addition to this, impersonating a weak permited account may cause some
other unexpected error.

If there are anything else unclear, please feel free to post here.

Thanks & Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)