A Second Look: Enabling ASP.NET 2.0 Localization in a DotNetNuke Application

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!

5 Comments

  1. From the Desk of Brandon Haynes » Enabling ASP.NET 2.0 Localization in a DotNetNuke Application

    October 29, 2008 @ 12:16 pm

    1

    […] Editor’s note: This approach has been obsoleted in favor of the more straightforward, core-friendly ASP.NET 2.0 Localization approach outlined here. […]

  2. Walt Garfield

    June 17, 2009 @ 2:31 pm

    2

    For the most part this works well. The only gotcha I found when using with 5.0.1
    is when a user makes changes to the base resx file which then has a Portal-0.resx prior to the .resx as user edits to the base resx file. Standard resourcekeys references work but not those referenced as meta:resourceykey. Do you see any way this can be resolved?

  3. Brandon Haynes

    June 17, 2009 @ 5:28 pm

    3

    As I recall, this will be difficult to resolve without registering custom languages on the installation machine. I will take a look at extending functionality to cover this case.

  4. Paul Chu

    March 23, 2010 @ 9:34 pm

    4

    Hi Brandon,

    Well, I was having localization problems on DNN 5.2.2 with a test C# module.
    I tried your build provider and it seems to be working.

    Wondering if the same localization problems still exist in DNN 5.

    Thanks for posting this very helpful post and sharing your code, Paul

  5. Brandon Haynes

    May 15, 2010 @ 10:58 am

    5

    Hi Paul,

    The big obstacle preventing DotNetNuke from allowing its internal localization and ASP.NET location to play nicely together was removed sometime around the 5.0.0 release. However, the final small change has not yet been made.

    There is a lot of work going on in the localization area right now, and we’ll likely have to see that play out before ASP.NET 2.0 localization is available. I’m also only loosely familiar with the changes in .NET 4.0 (I believe they are inconsequential), but that may also have an impact.

    Glad the build provider is working for you in the meantime!

    B

Log in