{"id":33,"date":"2008-10-29T10:01:58","date_gmt":"2008-10-29T14:01:58","guid":{"rendered":"http:\/\/blogs.law.harvard.edu\/brandonhaynes\/?p=33"},"modified":"2008-10-29T10:01:58","modified_gmt":"2008-10-29T14:01:58","slug":"a-second-look-enabling-aspnet-20-localization-in-a-dotnetnuke-application-2","status":"publish","type":"post","link":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/2008\/10\/29\/a-second-look-enabling-aspnet-20-localization-in-a-dotnetnuke-application-2\/","title":{"rendered":"A Second Look: Enabling ASP.NET 2.0 Localization in a DotNetNuke Application"},"content":{"rendered":"

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

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

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

    I am pleased to announce a preview release of a custom BuildProvider that, to my knowledge, accomplishes all of these goals.<\/p>\n

    <\/p>\n

    For those not familiar with the issue at hand, I strongly recommend reading my previous entry<\/a>\u00a0for the relevant background information.\u00a0 The remainder of this discourse will assume such familiarity.<\/p>\n

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

    This time around, I elected to utilize a different approach.\u00a0 This revision includes a\u00a0 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.\u00a0 Further, custom extensions allow portal-specific resource customizations to extend to the ResourceManager (including both strongly- and weakly-typed access).<\/p>\n

    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).\u00a0<\/p>\n

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

    Configuration<\/h3>\n

    Configuration is straightforward, requiring only a single additional node in the web.config file (highlighted below):<\/p>\n

    <buildProviders><\/pre>\n
    <remove extension=\".resx\" \/><\/pre>\n
      <remove extension=\".resources\" \/><\/pre>\n
      <add extension=\".resx\" \u00a0\u00a0\u00a0<\/span><\/strong><\/pre>\n
    type=\"BrandonHaynes.DotNetNukeResXBuildProvider.ResXBuildProvider, <\/span><\/strong><\/pre>\n
    BrandonHaynes.DotNetNukeResXBuildProvider\" \/> <\/span><\/strong><\/pre>\n
    <\/buildProviders><\/pre>\n
    Here, we keep the existing DotNetNuke <remove> elements and add the new BuildProvider to the list.\u00a0 During startup, ASP.NET will utilize this BuildProvider to compile all files with the .ResX extension.\u00a0 This BuildProvider will handle strongly-typed class generation, ResourceManager decoration, and enable full ASP.NET localization within the application.\u00a0 That’s it!<\/p>\n
    CodePlex Project<\/h3>\n
    As I gather feedback on the approach, I am initially releasing the BuildProvider project as a beta release.\u00a0 Please understand that it is preview software, has undergone limited testing, and may break existing installations.\u00a0 Though I am not currently aware of any outstanding issues, please use caution in a production environment.\u00a0 Note that any custom BuildProvider, including this one, requires deployment in a Full Trust environment.<\/p>\n
    The project is available on CodePlex.\u00a0 Click here<\/a> to access.\u00a0 Full source is available.<\/p>\n
    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.\u00a0 It is greatly appreciated.<\/p>\n
    B<\/p>\n
    * 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.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"
    Some time ago, I\u00a0wrote\u00a0about an approach for enabling ASP.NET 2.0 localization within a DotNetNuke application.\u00a0 This approach not only required a core modification, but the change introduced a potential breaking change with third party modules.\u00a0 This was clearly unsatisfactory, and the fact that I was unable to fully solve the problem has been vexing me […]<\/p>\n","protected":false},"author":1933,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3062,142],"tags":[3367,3070,3366],"class_list":["post-33","post","type-post","status-publish","format-standard","hentry","category-dotnetnuke-dnn-content-management-system","category-technology","tag-aspnet","tag-dotnetnuke","tag-localization"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/posts\/33","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/users\/1933"}],"replies":[{"embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/comments?post=33"}],"version-history":[{"count":1,"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/posts\/33\/revisions"}],"predecessor-version":[{"id":198,"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/posts\/33\/revisions\/198"}],"wp:attachment":[{"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/media?parent=33"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/categories?post=33"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/tags?post=33"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}