Tuesday, August 23, 2005

HtmlInputFile problem uploading large files!

God I have spent nearly 4 days solid trying to work that one out!

Here is the challenge:
Basically there is by a size limit to the file you can upload to a webserver using the good old HtmlInputFile Input. By default this limit is 4Mb and it is set in the machine.config file on the web server:

httpruntime maxrequestlength="8192"

It is of course possible to override this value in your web.config file and make it web app specific.

The problem occurs when you try to upload something bigger than that... you will get a nasty DNS error because the asp.net worker process got its knickers in a twist on the webserver. It basically reached a memory threshold before it could do anything with the file!

A full explanation can be found here:

Anyway the bottom line is that it displays a nasty error to the user and the people I work for don't like that at all.

As a Google group lover I looked for an answer to that one for a lot longer than I originally thought I would have to and finally found this EXCELLENT article by Jesse Chunn:

Jesse you're the man! The little code snippet you posted is awesome in simplicity and it works great.

The trick is to use the global.asax file and to test the file contentLength for every single request made to the web server.

I post the code again:

Sub Application_BeginRequest(ByVal sender As Object, ByVal e As EventArgs)

' Fires at the beginning of each request
Dim i As Integer

'this number is in bytes, NOT kilobytes!!
Dim iMaxFileSize As Integer = 8000000
For i = 0 To Request.Files.Count - 1
If Request.Files.Item(i).ContentLength > iMaxFileSize Then
Response.Redirect("FileToBig.aspx?filesize=" & Request.Files.Item(i).ContentLength)
Exit For
End If

End Sub

A massive thank you to you my friend, you're a star in the developer's world!!!

Friday, August 12, 2005

Enterprise Library, not always the best option!

I had to say it, the Enterprise Library which I think is a brilliant repository of coding practices from Microsoft, is not always the best option!

I struggled a lot with it when trying to deploy it to a shared hosting environment and I finally gave up. I had to write this on the GotDotNet Message board:

"Enterprise Library and shared hosting
Posted on: 08/12/2005 02:11:21

Hi guys, ok I have now developed 2 reasonably big ASP.NET applications built on the Enterprise Library. One of them uses Data Access, Configuration, Caching and Security (DB) and the other one uses the Data Access and Caching. They are both intranets and although it took me quite some time to suss out how to get everything to work and to code/debug my VB.NET calls to the EL, I finally managed to get the sites working very well and I am quite impressed with some of the functionality in EL.

However I have to emphasize on the fact that I did struggle, it is not always developer friendly and you have a few obstacles to overcome (I guess it's still quite new so people are getting used to it!) and even though it is packed with very cool functionality I still think it is a sledgehammer to crack a nut. Compared to the old DAAB and the ever so friendly SqlHelper class, there is quite a big gap! Maybe you should think about the Enterprise Library Lite! (.NET Framework 2.0?)

The Enterprise Library is awesome when it comes to hosting a very complex web app yourself on your very powerful W3K Server on an AD Domain. But when your designing a very simple secure site hosted on a shared hosting environment with a simple SQL server backend, like it is the case 99% of the time (for me anyway), you are in for a big ride!!! No way I could run "InstallServices.bat" on the 3rd party shared hosting network of course, so you get the nice "Access Denied error" when you try to run the blocks because of the Instrumentation and Logging trying to access the EventLog...

I read Tom's blog: http://blogs.msdn.com/tomholl/archive/2005/02/18/376187.aspx

Tried what he suggested but was still getting errors from the Caching block even after turning off the Instrumentation altogether. After many hours of frustration, I just chose to give up, got rid of EL DLLs altogether and replaced them with the good old SqlHelper! Rewrote my data access layer, implemented a simple SQL server authentication mechanism with password encryption and swore I would never use EL again.

So end of story for me, a lot of time wasted, no will to get a dedicated server solution (too expensive) and therefore back to a normal plain old SqlHelper class, which I have to say now I kind of prefer to the EL!

At least it deploys to any server.

Sorry guys but I had to say it! On a different note, I still think the Enterprise Library Code is probably one of the best open source I have seen in terms of architecture and new ways of thinking blocks. Just make sure it is developer friendly and that you can deploy it to any .NET environment, especially remote with limited access rights!

Cheers, Etienne "