Hi Peter,

we recently updated our DNN from 5.5.1 to 5.6.0.
Since then I find dozens of entries in the site log:

[b]AssemblyVersion[/b]: 5.6.0
[b]PortalID[/b]: 5
[b]PortalName[/b]: Global Operations
[b]UserID[/b]: 1
[b]UserName[/b]: host
[b]ActiveTabID[/b]: 160
[b]ActiveTabName[/b]: Operations
[b]RawURL[/b]: /Operations.aspx
[b]AbsoluteURL[/b]: /Default.aspx
[b]AbsoluteURLReferrer[/b]:
[b]UserAgent[/b]: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; InfoPath.2; .NET4.0C; .NET4.0E; AudioRent Clair AG)
[b]DefaultDataProvider[/b]: DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider
[b]ExceptionGUID[/b]: 3f307ad1-31a3-4f1a-aa35-eab2132e83ad
[b]InnerException[/b]: The relative virtual path 'desktopmodules/bring2mind/dmx/app_localresources/sharedresources.resx' is not allowed here.
[b]FileName[/b]:
[b]FileLineNumber[/b]: 0
[b]FileColumnNumber[/b]: 0
[b]Method[/b]: System.Web.VirtualPath.FailIfRelativePath
[b]StackTrace[/b]:
[b]Message[/b]: System.ArgumentException: The relative virtual path 'desktopmodules/bring2mind/dmx/app_localresources/sharedresources.resx' is not allowed here. at System.Web.VirtualPath.FailIfRelativePath() at System.Web.Hosting.HostingEnvironment.MapPathActual(VirtualPath virtualPath, Boolean permitNull) at System.Web.Hosting.HostingEnvironment.MapPathInternal(VirtualPath virtualPath) at System.Web.Hosting.HostingEnvironment.MapPath(VirtualPath virtualPath) at DotNetNuke.Services.Localization.Localization.GetResourceFileCallBack(CacheItemArgs cacheItemArgs) at DotNetNuke.Common.Utilities.DataCache.GetCachedData[TObject](CacheItemArgs cacheItemArgs, CacheItemExpiredCallback cacheItemExpired, Boolean storeInDictionary)
[b]Source[/b]:
[b]Server Name[/b]: DEV-TECHNET

This only applies to portal 5. Our default portal 0 is running fine. (five is the only other portal we're running).
Also, DMX' Ajax UI does not cleanly render in this portal. We only see a white box with a grey title bar and that's all.
This portal's What's New is working perfectly. 

Best

-Chris

I think it's related to IIS and work that was recently done there on your site. We'll wait until the analysis comes in.

Peter

Hi Peter,

Meanwhile we've setup the whole server again.
Now it's 2008 R2 64bit, IIS7, SQL 2008 Advanced 64 bit, DNN 5.5.1, DMX 5.3.3, all (ASP- und IIS-) settings are default, all permissions are good.

Still the issue :-(

Whole installation as fast as a sports car :)

-Chris

Hi Chris,

Are you using any url rewriting stuff? Are you operating under partial trust? Maybe you can send me a SysInfo file (Admin > Get Help) so I can examine all parameters.

Best,

Peter

Hi,

I have same issue here for a custom module only. It is dynamically loading and using the resx of dnn through the localization class:

System.ArgumentException: The relative virtual path 'c:/mystuff/desktopmodules/admin/security/app_localresources/profile.ascx.portal-0.resx' is not allowed here. at System.Web.Hosting.HostingEnvironment.MapPathActual(VirtualPath virtualPath, Boolean permitNull) at System.Web.Hosting.HostingEnvironment.MapPath(VirtualPath virtualPath) at DotNetNuke.Services.Localization.Localization.GetResourceFileCallBack(CacheItemArgs cacheItemArgs) at DotNetNuke.Common.Utilities.DataCache.GetCachedData[TObject](CacheItemArgs cacheItemArgs, CacheItemExpiredCallback cacheItemExpired, Boolean storeInDictionary)

I think it is not allowed to call resources from one desktopmodule in another? However, other modules do the same. This tab however is using https instead. Maybe that is the cause?

Did you find solution yet? DNN 5.5.x had similar problems.

J.

Hi,

I can't really help here. As far as I can tell it is an external problem and not a DMX problem. We'll have to wait until someone had the same issue and resolved it and shares it here.

Peter

Hello,
I have the same problem after adding a custom attribute. Is it solved in 05.03.08 now?

No solution has come to light, no. We can't reproduce it and those that have had this issue have not come forward with a solution either. As far as we can tell it's an external issue.

Peter

I've looked at the problem again and noticed that it was my fault. There was a wrong value in the 'ResourceFile'-column (DMX_Attributes). :/

We're having this same trouble. The event log is filling faster than the system can purge it, and these are the majority of the errors in it. Each hit to a DMX page appears to generate 12 Event View Log records, all about the relative virtual path not being allowed. It tries several filename variation for the template's resource file. There is only one actual string in the resource file (Older Versions), and I don't think our template should even be using it as we only allow access to the latest version of the files.

What did you edit to fix the problem?

Here's a sample log entry:

---
AssemblyVersion: 6.1.5

PortalID: 0

UserID: 1

UserName: host

ActiveTabID: 59

ActiveTabName: Library

RawURL: /Support/HowCanWeHelpYou/Library/tabid/59/Default.aspx?EntryId=535

AbsoluteURL: /Default.aspx

AbsoluteURLReferrer:

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0

DefaultDataProvider: DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider

ExceptionGUID: 01d87512-508b-4dcb-a79d-9dd541b6bcb9

InnerException: The relative virtual path 'portals/0/dmx/viewtemplates/spec2/resx/sharedresources.resx' is not allowed here.

FileName:

FileLineNumber: 0

FileColumnNumber: 0

Method: System.Web.VirtualPath.FailIfRelativePath

StackTrace:

Message: System.ArgumentException: The relative virtual path 'portals/0/dmx/viewtemplates/spec2/resx/sharedresources.resx' is not allowed here. at System.Web.VirtualPath.FailIfRelativePath() at System.Web.Hosting.HostingEnvironment.MapPathActual(VirtualPath virtualPath, Boolean permitNull) at System.Web.Hosting.HostingEnvironment.MapPathInternal(VirtualPath virtualPath) at System.Web.Hosting.HostingEnvironment.MapPath(VirtualPath virtualPath) at DotNetNuke.Services.Localization.Localization.GetResourceFileCallBack(CacheItemArgs cacheItemArgs) at DotNetNuke.Common.Utilities.DataCache.GetCachedDataFromDictionary(CacheItemArgs cacheItemArgs, CacheItemExpiredCallback cacheItemExpired)
---

We're getting the error for:
sharedresources.resx
sharedresources.ascx.resx
sharedresources.portal-0.resx
sharedresources.ascx.portal-0.resx
sharedresources.host.resx
sharedresources.ascx.host.resx

(twice for each)

I should add that the site is running DNN 6.1.5 with DMX version 6.04 on IIS 6.5 on Window Server 2003.

As far as we can tell this is a DNN issue in combination with the way the site is configured in IIS. We don't have more information as we've never been able to reproduce it.

Peter

Peter,

I've narrowed down this behavior and I believe it may be something that would have to be patched inside DMX itself. NOTE: We are still on the 6.1.4 version.

We saw the error reported in this thread "the relative virtual path is not allowed here" and I have a theory on approximately where it might be occurring. Perhaps you could help me run to the end of this theory.

We saw these errors in the error log like everyone else. I noticed that they occurred while testing one specific scenario.

Of all the documents we link from DMX we found some would fail to stream to the browser when requested. Many common types like PDF and Word would generally opened fine.

Here is a sample link for something we might open: http://our.intranet.com/D...wnload&EntryId=14273

When I tested with PowerPoint (.PPTX) documents you might get ONE opportunity to "Open or Save" though I'd then be trapped in a state where the documents NEVER loaded properly. It was as though once a cache had been created, the environment became toxic. The browser window would choke up and display the general "This page cannot be displayed." after hanging for a bit. It was during this failure that the EventLog would show what appears to be an attempt to get a RESX file path using the DNN core library calls. See below...

System.Exception: The following resource file caused an error while reading: ---> System.ArgumentException: The relative virtual path 'sharedresources.portal-0.resx' is not allowed here.
at System.Web.VirtualPath.FailIfRelativePath()
at System.Web.Hosting.HostingEnvironment.MapPathActual(VirtualPath virtualPath, Boolean permitNull)
at System.Web.Hosting.HostingEnvironment.MapPathInternal(VirtualPath virtualPath)
at System.Web.Hosting.HostingEnvironment.MapPath(VirtualPath virtualPath)
at DotNetNuke.Services.Localization.LocalizationProvider.GetResourceFileCallBack(CacheItemArgs cacheItemArgs)
--- End of inner exception stack trace ---
at DotNetNuke.Services.Localization.LocalizationProvider.GetResourceFileCallBack(CacheItemArgs cacheItemArgs)
at DotNetNuke.Common.Utilities.DataCache.GetCachedDataFromDictionary(CacheItemArgs cacheItemArgs, CacheItemExpiredCallback cacheItemExpired)

I believe that the call being made to get the path for the 'sharedresources.portal-0.resx' would occur during these attempts to stream these documents to the browser. Either a failure of HTTP Context to be present or some kind of invalid argument (i.e. The relative virtual path being passed in) might be to blame.

Clearing browser cache resets the environment for another attempt. This is obviously not an acceptable workaround.

What are your thoughts?

Concerning the relative path error: I've tried recreating with the latest DMX and I can't. It is a part that I've reworked a few times and I'm confident it has been resolved.

Concerning the different download behavior between ppt and other files: all files are streamed to the client in the same way. It is the client that decides what needs to be done. Two parameters that the server sends can influence the client's behavior: the mime-type and content-disposition. Both can be set in DMX in the file types list. The content-disposition sets whether the browser should attempts to download or to view the file inline.

Peter

Peter,

We are not on the latest version (mentioned in a previous post) so perhaps there is/was a code change that fixes this. I suppose we have to upgrade to confirm this.

Please note, the client-side behavior is irrelevant if we are seeing a server-side error while generating a path. This is not a client-script error, nor a browser behavioral thing. Before now I had already reviewed and confirmed that the PPT and PPTX mime-types were correct in both DMX's filetype settings as well as the IIS server's recognized mimetypes.

Should we upgrade and resolve the issue I'll let you know.

FYI: The client seeing this issue grew frustrated with issues, partly DMX and partly just generalized things, and may not invest more time to fix it.

Also, is there a higher level of support offered by paid incident or something? I have other clients using DMX and 18 day turnarounds on forum posts make me concerned that I might be left in a lurch should I run into issues later.