Hello. We have SlickUpload 6 on Win2003 (and in the future on Win2008R2x64) in a .NET 4 website and this is my first try to get it working. I have an upload profile section configured as:

  <slickUpload>
    <uploadProfiles>
      <add name="customFileName">
        <uploadStreamProvider type="CustomLocation" location="" existingAction="Overwrite" />
        <uploadFilter type="Filter" />
      </add>
    </uploadProfiles>
  </slickUpload>

The httpModule is there:

   <httpModules>
      <add name="SlickUploadModule" type="Krystalware.SlickUpload.Web.SlickUploadModule, Krystalware.SlickUpload" />
    </httpModules>

Two questions. First, does uploadFilter work in our setup? I can't get it to use the IUploadFilter class "Filter" that sits in our App_Code folder. Second, is it possible to have something other than SlickUpload.axd process upload files? The two issues may be related.

Thanks!

Are you sure you're using the correct uploadProfile name? When you set an uploadFilter, it will be created and used during an upload. If it can't be created, the upload will error. I've retested upload filters several different ways and everything seems to work.

One thing to note, though -- you won't hit the upload filter at all for a GET request -- uploads are only possible through POSTs, so SlickUpload does a quick exit and doesn't handle GETs to the upload handler at all.

If nothing seems to be working, can you send me your .aspx, filter, and web.config? chrish at krystalware dot com.

As for the handler url, I'm curious to know -- what are you trying to change that to be and why? SlickUpload automatically registers SlickUpload.axd, but you can register other handler URL's if you want. Here's how:

- Add the handler to the system.web <httpHandlers> section (when you upgrade to IIS7, you'll need this in the system.webServer <handlers> section as well:

<httpHandlers>
        <add path="TestUpload.axd" verb="GET, POST" type="Krystalware.SlickUpload.Web.SlickUploadHandlerFactory, Krystalware.SlickUpload"/>
</httpHandlers>

- Enable uploads for that handler:

  <location path="TestUpload.axd">
    <slickUpload handleRequests="true" />
    <system.webServer>
      <security>
        <requestFiltering>
          <requestLimits maxAllowedContentLength="2072576000"/>
        </requestFiltering>
      </security>
    </system.webServer>
  </location>

- In your SlickUpload control, add the UploadHandlerUrl="~/TestUpload.axd" attribute. This will tell the control to use that new url rather than the default "~/SlickUpload.axd".

Ahh, I see. I remember working with you guys to implement this for SlickUpload 5 back in the day.

I'll take a look at this tomorrow and see if I can put together a sample for this.

A couple of questions in the meantime:

• Do you need to support both the SlickUpload client controls as well as your ActiveX/Java controls, or just the ActiveX/Java controls?
• Are you uploading multiple files in one request, or does each request have a single file?

I did a bit of testing, and it looks as if your current .uplx handler should work with a bit of tweaking.

Here's how to set that up:

• If you added an .uplx httpHandler mapping for the SlickUpload handler, remove that. All you need is your existing buildProviders mapping.
• Enable upload handling for the .uplx handler:
  <location path="UploadHandler.uplx">
    <slickUpload handleRequests="true" />
    <system.webServer>
      <security>
        <requestFiltering>
          <requestLimits maxAllowedContentLength="2072576000"/>
        </requestFiltering>
      </security>
    </system.webServer>
  </location>
• Add the defaultProfile="customFileName" attribute to the uploadProfiles element (or whatever you have named your profile). This will set it as the default, so it is used if you don't specify the upload profile.
• Change your handling code in the UploadHandler.uplx to resemble this:
  protected void Page_Load(object sender, EventArgs e)
  {
      UploadSession session = SlickUploadContext.CurrentUploadSession;
  
      if (session != null && session.UploadedFiles.Count > 0)
      {
          foreach (UploadedFile file in session.UploadedFiles)
          {
              // TODO: process file
          }
  
          SlickUploadContext.CommitSession(session);
      }
      else
      {
          // TODO: handle no upload
      }
  }

The above configurations should get you back to a url like http://[server]/UploadHandler.uplx, for the ActiveX/Java/raw browser stuff you have currently.

One note: the CommitSession call is required. If you don't commit the session, SlickUpload's stale session pruning will roll it back. SlickUpload 6 introduces the concept of upload sessions, which can be composed of multiple upload requests. Since everything isn't in one request (like it was in previous versions), there's the potential that some requests could succeed, some could fail, and then the client could abandon the session without completing it. To mitigate this, SlickUpload checks for uncompleted sessions that haven't been touched in 30 minutes (or whatever timeframe you configure) and rolls them back, deleting all uploaded files and removing all traces of the session. SlickUpload automatically commits the session when a completion handler is executed (like from the SlickUpload client controls), but in this case that won't happen. Thus, you need to call CommitSession manually.

I'd recommend using the SlickUpload.axd handler (or something mapped to it, as I described in my earlier post) for any pages that use the SlickUpload client controls and not the .uplx handler. You could make the .uplx handler work by having the form with the SlickUpload client controls post to the .uplx handler after, or using an AJAX completion to the .uplx handler, but then the handler would need to return different results depending on whether an browser or a ActiveX/Java component was doing the upload.

Depending on what you're doing in your post processing, another way to add post processing logic is to create a custom UploadStreamProvider and do the processing in the CloseFileStream method (if isComplete=true, the file was successfully uploaded).

Great!

You should still be able to use your .uplx handler for the session status XML handler if you want to, since SlickUpload won't handle GET's.

What info are you looking for on the upload sessions? Is this something you had working with SlickUpload5, but isn't supported in SlickUpload6? I've got a couple ideas about how to provide the information, but want to see what you need exactly to figure out which one will work the best.

First, a little explanation about Sessions and Requests. In SlickUpload 5, sessions and requests were one and the same. The SlickUpload client components sent an upload as one request, with all of the files were included in that request. In SlickUpload 6, the client components send the upload with individual requests, one per file. The session is the entity that ties everything together.

So, the typical flow for an upload of multiple files from a client will have one session (which is created upon receipt of the first request), multiple requests (each with one file), and then a separate completion request when the upload is done that completes and commits the session so that it isn't automatically rolled back.

If SlickUpload receives some requests but then the client goes dark, after a timeout (defaults to 30 minutes) SlickUpload will assume the client is gone, roll back the session, and delete any files that were uploaded.

This is why I mentioned that you'd need to call SlickUploadContext.CommitSession(SlickUploadContext.CurrentSession) -- since your scenario has only a single request per session and no completion request, you need to complete the session in the scope of that request so it doesn't get rolled back.

All that being said, there are two basic options for how to approach the stats functionality:

1. Inherit from InProcSessionStorageProvider and add a method that goes through its lists to pull out the information you need.
2. Inherit from whatever session storage provider you want, delegate to it to do most of the work, but override the SaveSession/SaveRequest/RemoveSession methods so you can store your own stats in whatever stats table you want (call the base implementation after you have stored your stats).

Setting defaultProfile in the web.config should make it pick up that profile if you don't specify one. Can you send me your code (to chrish@krystalware.com) so I can take a look and see if I see any issues there?