Silverlight/WP7 Resource Files and Binding - by Jeff Winn

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 628281 Comments
Status Closed Workarounds
Type Suggestion Repros 0
Opened 12/3/2010 8:18:05 PM
Access Restriction Public


I was looking into binding xaml directly to a resource file which contains generated code from resgen.exe rather than having to build my own class to access the resource strings. At a minimum this suggestion would affect both Silverlight and Windows Phone 7 development.

Basically, the issue is the Resgen tool included with the Windows SDK creates an internal constructor on the designer code it generates even though the class has been marked public. Since the class constructor is internal, it cannot be added directly to a xaml resource dictionary as shown below...

<Application x:Class="SilverlightApplication1.App" xmlns:local="SilverlightApplication1">
            <local:AppResources x:Key="LocalizedStrings"/>

Assuming in my above example, the resx file I added to my project was called AppResources.resx any attempt will result in AG_E_PARSER_UNKNOWN_TYPE exception to be thrown once the App.xaml is parsed.

One way around this problem is to use App.xaml.cs to manually create the instance in the App class constructor like so:

this.Resources.Add("LocalizedStrings", new SilverlightApplication1.AppResources());

However, while this approach works during runtime you will not be able to see anything during design time within Visual Studio.

My suggestion is to make the constructor from the generated code public if the public access modifier has been used. Although making it public for an internal class would have no effect, so the constructor could be made public permanently.
Sign in to post a comment.
Posted by Jeff Winn on 1/6/2011 at 2:35 PM
Ah, I wasn't aware of it already being out there. I know I searched for it before I spent the time to create this one.

However, after reading feedback from the other item it would be nice if we'd get a reason behind the design decision this time other than just closing it. If the logic is valid, I can see why... but it's not like they owe us an explanation for anything. I'm just curious why it'd be a design decision to keep the constructor internal.
Posted by StefanBeck on 12/28/2010 at 2:58 AM
BTW, this is a duplicated report:

However, the solution "by Design" is not sufficient for all scenarios for different reasons:

1) Silverlight / WP7 cannot bind to static members in WPF.
2) The compiler message which is generated is not clear: "XmlParse Exception AG_E_PARSER_UNKNOWN_TYPE". People spend hours to figure out that this error is related to the resx files.

I've seen microsoft evangelists at several conferences (TechEd, Shape,..) during the last 4 years and its always funny to hear them explain "Now, we need to open the resx file and change the constructor from internal to public" when they talk about L10N.

Sure, there is a work-around available, but forums are full of exactly this question.
Posted by Jeff Winn on 12/4/2010 at 10:04 PM
I made an example Silverlight 4 solution in Visual Studio 2010 demonstrating the usage of the generated files with a simple view. The file has been attached, but isn't available (yet).
Posted by Microsoft on 12/3/2010 at 8:23 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(