DotNetNuke

Re: DNN 4.0 Module upload issue

jparmar — Fri, 13 Jan 2006 20:49:36 GMT

I upgraded to version 4.02. Had some problems durring install and then could not login to my host account becuase the machinekeys had changed in the web.config file.

I got that sorted all out but still can not upload anything to the site. Could it be folder permissions? I added an IUSR_WebserverName and gave it write permissions but still no luck.

HELP

Re: DNN 4.0 Module upload issue

anthony.glenwright — Thu, 12 Jan 2006 23:50:29 GMT

Have you downloaded/installed DNN 4.0.2? This version fixed the issue for me.

Re: DNN 4.0 Module upload issue

jparmar — Thu, 12 Jan 2006 22:56:17 GMT

I made the changes to the web.config file and the "Invalid postback or callback argument" error has disappeared however I am still not able to upload files of any sort including modules.

Any idea.

I am usind dnn4

Re: DNN 4.0 Module upload issue

WayneHoulden — Tue, 06 Dec 2005 11:24:54 GMT

It seems to be related to the size of the zip file - I uploaded smaller module zips without a problem.

Change (or add) the attibute requestLengthDiskThreshold="8192" to httpruntime in the web.config - that seems to fix the problem.

Re: DNN 4.0 Module upload issue

robaxx — Wed, 16 Nov 2005 00:34:28 GMT

RMASSEY1 wrote:
Nice the requestLengthDiskThreshold="8192" fixed my problem also. I did manage to figure out the other problem. It shows up in a few posts as well. I thought I would post the solution here also.

In the page level options of the web.config file add enableEventValidation="false". This was a last minute add to the DOTNET 2.0 release.

Brilliant! This is the solution. All three things that did not work now work... uploading modules, creating folders and uploading files.

Well done... pin this to the top of the forum if it is confirmed to be the full fix.
Rob

Re: DNN 4.0 Module upload issue

RMASSEY1 — Tue, 15 Nov 2005 22:35:06 GMT

Nice the requestLengthDiskThreshold="8192" fixed my problem also. I did manage to figure out the other problem. It shows up in a few posts as well. I thought I would post the solution here also.

In the page level options of the web.config file add enableEventValidation="false". This was a last minute add to the DOTNET 2.0 release.

In the Web.Config file locate this section and add enableEventValidation="false".
    
    <pages validateRequest="false" enableViewStateMac="true" enableEventValidation="false">
      <namespaces>

Here is the link to Microsofts class library reference on this property.
http://msdn2.microsoft.com/en-us/library/system.web.ui.page.enableeventvalidation.aspx

Re: DNN 4.0 Module upload issue

dstgroup — Tue, 15 Nov 2005 20:12:19 GMT

I tried a quick work around by saving to Session state instead of the DataCache. This failed as well, so I quess there must be some serialization going on there as well. And in hind sight, even if it did work, some of the providers for session state such as the SqlProvider definantly will serialize objects if used.

The only thing I can think of, is to save the file stream every time cmdAdd_Click is called. So instead of saving the HttpInputControl to the DataCache, you serialize the file itself. First, this would work for both 1.1 and 2.0 versions of DNN. And as an added benefit, the entire serialized object will not be saved, just the file itself, so there may be performance gains this way.

Re: DNN 4.0 Module upload issue

cathal — Tue, 15 Nov 2005 17:55:19 GMT

Thank you for continuing to look for this Geoff, you efforts are much appreciated. Your explanation ties in with what I've found so far (though you've drilled down further). The htmlinputfilecontrol serialization also explains why files dropped in the install subfolders work ok.

Thanks,

Cathal

Re: DNN 4.0 Module upload issue

dstgroup — Tue, 15 Nov 2005 17:34:26 GMT

I believe I’ve figured out why the “Cannot access a closed file.” bug is being thrown. It is due to changes in the Framework 2.0 as well as how DNN handles multi file uploads. ASP.Net 1.1 handled uploaded files but streaming them all to memory. This caused problems for some sites that needed to handle high volumes of uploaded data.

In 2.0, if files are larger than the value specified in the “requestLengthDiskThreshold” property of the HttpRuntime object, the file is cached to disk. This can be set in the webconfig file and the default is 80kb, although the documentation incorrectly states that it is 256kb. The cached file is created several directories below the “ASP.NET Temporary Files\” folder, in a directory named “uploads”. It is created with the FileOptions.DeleteOnClose bit set which causes it to be deleted when the stream is closed.

DotNetNuke handles multiple file uploads by “storing the Input HtmlInputFile control” in the DataCache when the “Add” button is clicked. When this happens, the HtmlInputFile control is serialized which causes the underlying stream to close, and therefore the file to be deleted. When the user clicks upload, the DataCache deserializes the HtmlInputFile control. When the underlying stream is accessed the error is thrown because not only is the stream closed, the file it uses has been deleted.

I’m not sure what the correct fix for this is, but storing it in the DataCache is the wrong route for 2.0, even though it was the correct thing to do in 1.1. I’m going to try a couple of things and I’ll let everyone know what I find.

Re: DNN 4.0 Module upload issue

adb040672 — Tue, 15 Nov 2005 12:30:52 GMT

This worked. Thank you. Hopefully this has helped other users as well. Great job Will.

Thanks

Andrew
Baltimore, MD

Re: DNN 4.0 Module upload issue

tazzman — Mon, 14 Nov 2005 21:18:30 GMT

nettech wrote:

Add this to your web.config to fix the problem. It should be around line 194 in your web.config.
<httpRuntime useFullyQualifiedRedirectUrl="true" maxRequestLength="8192" requestLengthDiskThreshold="8192" />

I'm not sure if this is the best fix, but it does enable you upload and install.

This is the article I found that talks about this new property.
http://msdn2.microsoft.com/en-us/library/h2e8928c

Hope this helps,
Will

You rock this works if I use only the install zip files for the modules. If I use the install with source I get errors

Re: DNN 4.0 Module upload issue

dstgroup — Mon, 14 Nov 2005 17:49:04 GMT

After shutting down every unecessary service on my computer including AV scanners etc, the problem persited. So I did some more work with Reflector and Filemon. It seems that deep down in the framework, the temporary file created when the uploaded file exceeds the RequestLengthDiskThreshold has the FileOptions.DeleteOnClose bit set. I can see the file get created and read from. Then for some reason the ASP.NET worker process calls close on the file, and it is deleted. Then it tries to read from the stream when DNN tries to save the stream, but of course it is no longer there and the error shows it's ugly head. Now if I can figure out what the heck is closing the file. Anyone have any ideas? Does DNN have an httpmodule\httpHandler or something that would modify uploaded streams?

Re: DNN 4.0 Module upload issue

dstgroup — Mon, 14 Nov 2005 00:10:41 GMT

I did some digging using Reflector, and the default is actually 80K not 256 bytes as stated in the docs. The temp file created on disk by the framework resides in the Temporary ASP.NET directory. I'm going to look at anything that may be affecting this from working properly such as AV scanners etc. I'll let everyone know.

Re: DNN 4.0 Module upload issue

cathal — Sun, 13 Nov 2005 20:13:17 GMT

That does work, but I'm not so sure it's the final solution, as all that value does is determine how much is worked with in memory, and how much is transferred to disk. At the minute we're getting the default, which is 256 bytes, so it means that most of the content is streamed to disk. Changing the value as indicated just makes it work as it did in asp.net 1.1 i.e. steam to ram. I think that may be something else at the root of this problem (it could even be a permissions problem - as i'm not sure where the stream goes when it's transferred to disk i.e. if it goes to c:\winnt\temp users maynot have write access to that folder), but Will's solution will work in the interim whilst we try to get to the root of this problem.

Cathal

Re: DNN 4.0 Module upload issue

mikeh36 — Sun, 13 Nov 2005 20:11:25 GMT

Will, I"ve said it before, I'll say it again. "You Da Man!!!"