Note: this entry has moved.
Sometime ago I posted this and this about how the .NET framework itself and lots of Microsoft applications use the same approach for handling resource localization.
Both posts were commented by Sebastien Lambla and Daniel Cazzulino pointing out a few “issues” found in the Everett implementation of the SR type. At that moment, although I knew these “issues” were already fixed in the Whidbey bits I was testing, I wasn’t allowed to post about it until after the PDC03 because of NDA matters (although something may have slipped through a comment…).
But the big news is not about minor fixes… Let’s see what Whidbey brings so you don’t have any excuses now to not follow the SR type approach:
Great News #1: An updated resgen.exe
The days of coding your own SR type are gone. The resgen.exe utility was updated to support the generation of a strongly typed resource class (/str option) through the use of CodeDOM. This means that you can feed it a .resx file with the following:
<data name="NotEnoughMemory">
<value>There is not enough memory to complete the requested operation.</value>
</data>
<data name="FileNotFound">
<value>The specified file was not found.</value>
</data>
And you will get back a class definition like this:
public sealed class RssControl {
private static System.Resources.ResourceManager _resMgr;
public static System.Resources.ResourceManager ResourceManager {
get {
if ((_resMgr == null)) {
System.Resources.ResourceManager temp = new System.Resources.ResourceManager(typeof(ControlA));
System.Threading.Thread.MemoryBarrier();
_resMgr = temp;
}
return _resMgr;
}
}
public static string FileNotFound {
get {
return ResourceManager.GetString("FileNotFound");
}
}
public static string NotEnoughMemory {
get {
return ResourceManager.GetString("NotEnoughMemory");
}
}
}
Then you could use it from your code like this:
throw new Exception (RssControl.FileNotFound);
This sounds pretty cool but you still have some chores to perform by hand: run the command line utility resgen.exe, add the generated code file to your project, compile it and repeat this process every time the .resx file is modified.
Great News #2: Whidbey can do the work for you
For all lazy developers out there: good news is you don’t have to perform the above mentioned tasks in order to get your strongly typed resource class. You only drop your .resx file into the \Code folder and you’re ready to go. Whidbey will generate the resource class for you plus something definitively cool: VS.NET will automatically support intellisense for it. Want to modify the existing .resx? Just go ahead, save it, and the class (and intellisense support) will be updated accordingly. I believe this is as lazy as it can get.
What’s the magic behind all this?
Build Providers. You can now (in Whidbey, that’s it) participate in the build process of your application. You code a type that implements IBuildProvider and you register it in web/machine.config against the file extension you’re interested in handling (i.e.: System.Web.Compilation.ResXBuildProvider is the one in charge of .resx files). I promise I’ll posting more on build providers in the next days.
Lastly, just be aware that because of a few bugs in the current PDC03 build you may not get a totally friendly experience, i.e. you may notice that your app doesn’t automatically pick up changes made to files (.resx or any other type) located in the \Code folder thus requiring an additional application restart until that happen. I found about this the hard way :-( but thanks to a quickly follow up with the ASP.NET team this was traced down and should be already fixed.