Tuesday, July 7th, 2009
While working with ASP.NET 2.0 I discovered a problem with uploading of a file and processing the stream serverside. After a while I searched for the same problem. The error is got over and over was: System.ObjectDisposedException: Cannot access a closed file. Off-course other people had the same problem and it seems to be that ASP.NET 2.0 handles uploads differently than ASP.NET 1.1.
The following link explains exactly what causes the problem and how to solve it.
Some extra (little) information can be found on the MSDN site.
Posted in .NET Development, ASP.NET | 5 Comments »
Tuesday, July 7th, 2009
In my former post I recommended to read the forum post following the link beneath it. The solution of the problem is to far reading in the post, I decided to put the solution in this new post and explain a little about it. The link further on is to the MSDN online library about this topic.
<httpRuntime executionTimeout="90"
maxRequestLength="4096"
useFullyQualifiedRedirectUrl="false"
requestLengthDiskThreshold="4096"/>
executionTime: The maximum time the upload can take to execute (easy nah).
maxRequestlength: The maximum length in KiloBytes the request me be. By default this is 4096KB (4mb).
useFullyQuallifiedRedirectUrl: Something about a fully qualified url from client redirects (mostly web browser redirects) . By default this settings is "false".
requestLengthDiskThreshold: This one is a bit more nasty. Microsoft says "The number of bytes that indicate the input-stream buffering threshold". The number may never exceeds the maxRequestLength. If so all the bytes are written to disk. This means more space is allocated then needed. So you have created extra space for unwanted activity on your disk. Someone could upload a nasty piece of software in the extra space allocated. By default the size is 256KB. If all these settings have been configured right, you shouldn’t have any problem uploading files which do not exceed the given boundries.
Find more information on MSDN.
Tags: ASP.NET, disk, execution, file, fully, length, max, problem, qualified, redirect, request, time, treshold, upload, url, use
Posted in .NET Development, ASP.NET | 3 Comments »
Sunday, April 1st, 2007
The usual way to implement configuration settings in your website is trough a ASP.NET web.config file in your website. It can be placed in any folder in the website. When using Sharepoint Portal Server (SPS) Windows Sharepoint Services (WSS) you have to deal with several place in which web.config files exists and have to be configured.
Usually a web.config exists in the virtual server and in the layouts directory. I assume that everyone working with sharepoint technology knows what a virtual server is. If not read a SPS manual to know what I’am talking about. This layouts directory is available from all virtual servers and the web.config also off-course. The physical path of the config file looks something like:
c:\windows\program files\common files\microsoft
shared\webserver extensions\60\templates\layouts
When adding, for instance, key/value pairs or register the session state module in the httpHandler section you have to keep in mind what purpose these settings have. If you have an application available only within one virtual server and only installed in the virtual serves then you only have to update the virtual servers web.config. If you are planning to install web applications which have to operate throughout the SPS installation take care to put the right configuration settings in the right configuration file.
Tags: configuration, Sharepoint, web
Posted in .NET Development, Sharepoint | 2 Comments »