After 3 beta releases and many comments and emails from users it’s time to release the first stable version of the ASP.Net file upload module. This release contains a number of bug fixes and feature enhancements based on requests I have received. Thanks to everyone who has taken the time to implement the module and test it- I don’t think getting to this point would have been possible without you all.

As usual the Visual Studio 2008 solution is available in the downloads section of this site. I’ve also updated the demo site to allow browser testing.

I’ll go through the changes one by one.

Browser testing extended - Opera support

I have now tested the module on the following browsers:

• Internet Explorer 6/7
• Safari 3.1.2 on OSX
• Firefox 3.0.1 on OSX
• Firefox 3.0.1 on Windows
• Opera 9.5.1 on Windows
• Opera 9.5.1 on OSX

The main change here is that I’ve included Opera support. This turned out to be a great deal more difficult than I had expected. Opera 9+ is now supported fully with the exception of the progress bar. It seems that Opera blocks the UI during a file upload meaning that the modal box based AJAX progress bar never updates. For this reason, on Opera the non-script progress bar will automatically be used (see below). This means that Opera users at least get a progress bar- if not as nice.

I have tested all of the above browsers with and without javascript enabled and not found any issues.

File input styling now optional

The technique of styling file input controls that I have used may not be suitable for all purposes. For that reason I have made it optional. To turn file input styling on set the ApplyStyles property of the DJFileInput control to true. The default is now false.

Styling turned off	Styling turned on

If javascript is not enabled on the browser then styling will be turned off automatically.

Better accessibility

This release of the module will work entirely without javascript enabled and degrade gracefully on all browsers I have tested on. This is done by importing a secondary style sheet using javascript which expands all of the file inputs in a control and hides the remove and add buttons.

The accessibility styling changes are accompanied by a non-script iframe based progress bar which kicks in automatically if script is not enabled. This results in a display something similar to the following which is from Opera 9 with script turned off.

As a reminder, the default AJAX based progress bar looks like this:

The basic accessibility features are enabled by default and you don’t have to do anything to make them work. If you want to use the non-script progress bar then you need to place one instance of the DJAccessibleProgressBar control somewhere on the page.

<cc1:DJAccessibleProgressBar ID="DJAccessibleProgrssBar1" runat="server" />

The non-script progress bar needs access to the UploadProgress.aspx page which is included in the project. You can set the URL of this page using the ProgressURL property of the DJAccessibleProgressBar if you need to move it for any reason.

Note that if script is enabled on the browser then the non-script progress bar will automatically remove itself and be replaced with the default modal box version. If you need to use the non-script version even if script is enabled then set the ShowProgressBar property of the DJUploadController to false.

Access to form fields from IFileProcessors

I’ve had a few questions around accessing form fields on the same page as file upload controls. All fields on the form are parsed by the upload module (file uploads or otherwise) but non-file upload fields are not available until the module has finished processing.

The requests I’ve had centered around a need to capture information from the user on the same page as the file upload control which would then affect the way the IFileProcessor deals with the file. Up to now the advice I’ve been giving has been to capture these details on a preceeding page and pass them into the upload page via request variables- this is still valid but doesn’t allow for the controls to all be on the same page.

I’ve now added logic into the form processor which stores the names and values of all form fields as it goes. These are then passed into the IFileProcessor which can use them as it sees fit. The only restriction is that the IFileProcessor will only have access to fields which preceeded the corresponding file input on the form.

To accomplish this the IFileProcessor interface has been changed very slightly. The StartNewFile method now has a new parameter PreviousFields which is a dictionary of all fields that have been parsed so far.

        /// <summary>
        /// Starts a new file.
        /// </summary>
        /// <param name="fileName">File name.</param>
        /// <param name="contentType">The content type of the file.</param>
        /// <param name="headerItems">A dictionary of items pulled from the header of the field.</param>
        /// <param name="previousFields">A dictionary of previous fields.</param>
        /// <returns>An optional object used to identify the item in the storage container.</returns>
        object StartNewFile(string fileName, string contentType, Dictionary<string, string> headerItems, Dictionary<string, string> previousFields);

To take a trivial example, imagine that there were to be a drop down list of prefixes which must be selected for an upload control. When the file was created, the prefix would be applied to the file name. This is an example of information which is not available until the form is processed.

To accomplish this a drop down list called lstFilePrefix is placed on the form before the related file upload control. Then in the IFileProcessor the prefix can be applied with the following code by checking the PreviousFields dictionary for the control ID of the list.

/// <summary>
/// Starts a new file.
/// </summary>
/// <param name="fileName">File name.</param>
/// <param name="contentType">The content type of the file.</param>
/// <param name="headerItems">A dictionary of items pulled from the header of the field.</param>
/// <param name="previousFields">A dictionary of previous fields.</param>
/// <returns>An optional object used to identify the item in the storage container.</returns>
public object StartNewFile(string fileName, string contentType, Dictionary<string, string> headerItems, Dictionary<string, string> previousFields)
{
    string prefix = String.Empty;

    _errorState = false;
    _headerItems = headerItems;

    // Get the prefix from the drop down list
    if (previousFields.ContainsKey("lstFilePrefix"))
    {
        prefix = previousFields["lstFilePrefix"];
    }

    try
    {
        _fileName = fileName;
        _fullFileName = _outputPath + prefix + Path.GetFileName(fileName);
        _fs = new FileStream(_fullFileName, FileMode.Create);
    }
    catch (Exception ex)
    {
        _errorState = true;
        throw ex;
    }

    return null;
}

I’ve provided an example processor (FieldTestProcessor.cs) in the library.

Immediate termination of requests that are too large

One problem discovered in previous betas was that if a file were uploaded which exceeded the maxRequestLength setting then the progress bar would freeze. Actually, I found this to be an IIS 6 specific issue. Although the module correctly terminated the request it would not end until the entire file had been read in- even though the file would never be processed. This meant the progress bar was left hanging looking like the application had frozen.

To get round this I have added some javascript to the progress bar which cancels the request when the upload progress service informs it that a request was recieved which was too large. This prevents the progress bar from looking like it is frozen.

Note that the progress bar would eventually disappear once IIS 6 correctly ended the request, so the script is merely a user convenience.

File extension validation moved

In previous versions of the upload control file extension validation was handled via script in the styled input controls. The user would be informed via a message box if they picked a file with an invalid extension. This has now been moved to a custom validator on the form since the styling can be turned off. This of course means that the user will not be informed of invalid extensions until they attempt to submit the form.

Note that file extension validation is only carried out on the client. If you need to implement server validation then check in the StartNewFile method of your IFileProcessor and throw an exception if an invalid file extension is found. This will result in the erronous file being placed in the ErrorFiles collection of the UploadStatus.

Documentation

Documentation for the module is available on this page. The basic documentation is a collection of the most important parts from the previous posts as the module was developed.

Setup kits

Setup kits for the module and example application have been placed in the downloads section.

Looking forward

I think I may have said in a previous post that I wasn’t going to put any more features into version 2 of the module. Obviously a few have crept into this release (ahem ;-), but I think version 2 is now feature complete.

I’ll fix any bugs or issues which anyone encounters (just post a comment or send me an email) and make service releases as appropriate.