From the Desk of Brandon Haynes

Some time ago, I wrote about an approach for enabling ASP.NET 2.0 localization within a DotNetNuke application.  This approach not only required a core modification, but the change introduced a potential breaking change with third party modules.  This was clearly unsatisfactory, and the fact that I was unable to fully solve the problem has been vexing me for some time.

As my research on the recently-released Linq to Sql Adapter (currently hosted on CodePlex) wound down, I decided to investigate a new approach to solving the problem.  In my opinion, an optimal solution would fulfill the following requirements:

1. Require no core changes
2. Be side-by-side compatible with the existing DotNetNuke localization services
3. Require little configuration by a hosting user
4. Allow strongly-typed per-portal and per-culture access to existing global DotNetNuke resources
5. Minimal additional in-memory footprint and reasonable performance
6. Enable use of the meta:resourcekey attribute in DotNetNuke modules
7. Be fully compatibility with third-party modules

I am pleased to announce a preview release of a custom BuildProvider that, to my knowledge, accomplishes all of these goals.

For those not familiar with the issue at hand, I strongly recommend reading my previous entry for the relevant background information.  The remainder of this discourse will assume such familiarity.

The previous approach failed in satisfying two of the more important requirements above (specifically (1) and (7) above).  A core change was necessary to keep portal-specific localization files out of the App_GlobalResources directory where ASP.NET would choke during automatic compilation.  This core change caused trouble with pre-compiled third-party modules because of the compile-time linking of publicly exposed constant values.  Clearly unsatisfactory, and clearly a dead-end.

This time around, I elected to utilize a different approach.  This revision includes a  custom BuildProvider which handles the full compilation life cycle for ResX files; in this manner such files may continue to exist in the App_GlobalResources directory and be fully side-by-side compatible with the DotNetNuke localization system.  Further, custom extensions allow portal-specific resource customizations to extend to the ResourceManager (including both strongly- and weakly-typed access).

For example, the strongly-typed variable (enabled via this BuildProvider) Resources.GlobalResources.Error_Text will consistently yield the same value obtained through a DotNetNuke.Services.Localization.Localization.GetString(“Error”, Localization.GlobalResourceFile). 

Similarly, a meta:resourcekey attribute on an appropriately named control will yield the same value obtained through a call to UserModuleBase.GetLocalResourceObject(…).

Configuration

Configuration is straightforward, requiring only a single additional node in the web.config file (highlighted below):

<buildProviders>

<remove extension=".resx" />

  <remove extension=".resources" />

  <add extension=".resx"    

type="BrandonHaynes.DotNetNukeResXBuildProvider.ResXBuildProvider, 

BrandonHaynes.DotNetNukeResXBuildProvider" /> 

</buildProviders>

Here, we keep the existing DotNetNuke <remove> elements and add the new BuildProvider to the list.  During startup, ASP.NET will utilize this BuildProvider to compile all files with the .ResX extension.  This BuildProvider will handle strongly-typed class generation, ResourceManager decoration, and enable full ASP.NET localization within the application.  That’s it!

CodePlex Project

As I gather feedback on the approach, I am initially releasing the BuildProvider project as a beta release.  Please understand that it is preview software, has undergone limited testing, and may break existing installations.  Though I am not currently aware of any outstanding issues, please use caution in a production environment.  Note that any custom BuildProvider, including this one, requires deployment in a Full Trust environment.

The project is available on CodePlex.  Click here to access.  Full source is available.

As I work to confirm that this BuildProvider works properly across a wider variety of installations, I would appreciate any and all feedback about the experiences of those using it.  It is greatly appreciated.

B

* Installation of this module will still require the manual web.config modifications outlined above; at some point I will likely release a 5.0-compatible package that performs this task automatically.

Be Sociable, Share!

• 
•