Testing with DNN 5.0.1

Jun 17, 2009 at 7:41 PM

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 prior to the .resx (filename.ascx.Portal-0.resx) as user edits to the base resx file. Standard resourcekeys references work but not those referenced as meta:resourcekey. Do you see any way this can be resolved?

Jun 17, 2009 at 10:40 PM

Hi WGarfield,

I believe this is currently unsupported by the BuildProvider, but I will look into fixing it in a future release.  I don't recall offhand how I am handling the Portal-n resource files, but assuming that I am parsing and loading them into memory, then I should have enough context to get a portalId during a runtime request.  The issue will be how cascading missing keys are handled; this might require cross-resource file synchronization, something that could quickly become intractable.


Jun 1, 2011 at 6:52 PM

Hi Brandom
This provider works perfectly for my purposes , in local mode, but not in the production server, which is a shared hosting.  It gives me a security error...

Security Exception

Description: The application attempted to perform an operation not allowed by the security policy.  To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file. 

Exception Details: System.Security.SecurityException: Request for the permission of type 'System.Web.AspNetHostingPermission, System, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.

It seems that this dll can not run on medium trust level ( Medium Trust ), Said me from the hosting that can not be changed.The question is whether you can tell me some solution to avoid this error.

Thanks for this excellent tool

Jun 1, 2011 at 7:14 PM

Hello Taeldany,

As I mention in the project description, because the base System.Web.Compilation.BuildProvider has an InheritanceDemand (and System.Resources.ResXResourceReader has a LinkDemand) requiring full trust, this project is only operational on installations with this level of authorization.

There will be no way to avoid this reality; both the InheritanceDemand and LinkDemands exist to prevent malicious parties from interfering with the normal ASP.NET compilation process, and the localization approach that I've taken with the project depends on custom complication.  Note that you may circumvent the issue by installing the provider into the GAC, but in a shared hosting environment this may be an uphill battle.

I certainly wish it were possible to work around this such that the provider could be deployed in medium trust!