WinRes: Improvements in Whidbey
One of the first posts I made, after starting this blog, was about WinRes, a UI localization tool that ships with the .NET Framework SDK. The reason I wrote that post was that I had been increasing noticing how many people had the same set of issues with WinRes, and were having trouble resolving them, given that there isn't much documentation on MSDN about it. The information in that post gives a general understanding of how WinRes works and helps you debug the most common problems you may run into.
Ofcourse, simply documenting the issues is not enough, so we have attempted to improve the tool in Whidbey (.NET 2.0). Here are some of the improvements we have made:
1) Better error reporting - The single biggest problem users had with WinRes was not the errors, but the fact that it was very difficult to diagnose them. Many a time, WinRes simply failed to load a resource file and displayed an extremely informative message like 'Unknown item' or ' Item not found'. Not surprisingly, the user was left with no clue with what to do next. What's worse is that the typical user of WinRes is a localization/language expert, not a developer who can be expected to debug his/her way through the problem. I am happy to say that the error reporting is much improved in Whidbey. In typical cases, WinRes should be able to give a clear and specific indication of what the problem is, like the particular element in the resx that is invalid or which component it was not able to parent correctly and so on. It still may not be totally obvious how to resolve the problem, but you should atleast have something specific to go on. There will still be cases when WinRes will not be able to clearly pinpoint the problem, but it should, as a last resort, atleast show you what exception occured.
2) Robustness - A related issue with WinRes' loading mechanism was its sensitivity to problems. For example, it used to often fail to load an entire dialog just because it couldn't find one component's assembly or found one property it could not interpret. In Whidbey, WinRes is much more resilient to issues like these. In most cases, it will load the dialog inspite of such errors and report to you what errors occured in a textbox below the designer (much like the tasklist in Visual Studio). For example, if a component's type is not found, it will load the dialog and use a place holder control for that dialog, so that you can continue localizing (although I strongly recommend you ensure all the assemblies that are referenced in the resource file are placed either in the GAC or in the same directory as WinRes.exe, so it can locate and load them).
3) Support for VS localized resx files - One limitation of WinRes in v1.0/1.1 was that it required localized resx files (like Form1.ar.resx) to be self contained, in the sense that they had to have all the localizable properties defined in them. However, if you used Visual Studio for localization, the resx files it produced only contained diffs from the parent culture, which is more efficient and fits into the runtime resource loading behavior. These VS localized resx files could not be opened in WinRes, since it did not support the use of multiple resx files to load the dialog. In Whidbey, WinRes has the ability to do this and if you place the parent culture resx files in the same directory as the file you are trying to open, it should be able to pick them up and load the dialog.
4) Some support for public inherited controls - In v1.0/1.1, WinRes had trouble loading dialogs that had public inherited controls. We have fixed this issue in Whidbey and it should now be possible, in typical cases, to open these dialogs without problems. Note though that there will always be limitations in this area. There are many complex inheritance cases that we will still not be able to support (not only in WinRes, but even in the VS designer). Visual inheritance, though a tempting design choice, is fraught with many problems - but let me save that rather controversial topic for a separate post :-)
These are the major issues - besides these, we have fixed several small (yet irritating) bugs and improved the UI a bit. WinRes also supports the new designer improvements like snap lines for layout, since its designer has been rewritten to use the Whidbey designer hosting API. See also this post for improvements to localization in general in Whidbey.
If you have a chance to try out WinRes in Whidbey builds and find any issues you would like resolved, do let us know through MSDN Product Feedback. Note that some of the improvements mentioned above may not have made it into Beta 1 or the recent CTP builds, but should be available in the Beta 2 release.
In summary, WinRes is a useful, free tool that handles the most common and basic UI localization scenarios. For more advanced cases, users may prefer to use one of the third party localization tools available.