I just saw this article with computer quotes, and I found it to be quite hilarious.

“The Internet?  We are not interested in it.”
– Bill Gates, 1993

“Pessimists, we’re told, look at a glass containing 50% air and 50% water and see it as half empty.  Optimists, in contrast, see it as half full.  Engineers, of course, understand the glass is twice as big as it needs to be.”
– Bob Lewis

“It was a joke, okay?  If we thought it would actually be used, we wouldn’t have written it!”
– Mark Andreesen, speaking of the HTML tag BLINK

“Perl: The only language that looks the same before and after RSA encryption.”
– Keith Bostic

“Yes, we have a dress code. You have to dress.”
– Scott McNealy, co-founder of Sun Microsystems

And finally, since I’m working with UXP professionals:

“We have to stop optimizing for programmers and start optimizing for users.”
– Jeff Atwood

For more great quotes, check here.

Welcome to part 3 of my little series of creating an Asp.net component that allows to upload files of several megabytes without connection timeouts.

In part 1, I explained how the Silverlight component was built and in part 2 the backend service was discussed. In this third and last part I will explain the reusable ASP.Net server control that combines the features into a plug and play component.

The component will solve the following problems:

• How do I host the SilverLight component?
• How do I know when the upload has completed?
• How do I retrieve the contents of the file?

Hosting the SilverLight component

The SilverLightUploader control overrides the CreateChildControls and embeds a System.Web.UI.SilverlightControls.Silverlight component to host the uploader. The control provides for a couple of properties and some are passed on to the silverlight component by providing some initialization parameters. These include:

• The url of the webservice to be called
• The location of the SilverLightUpload.xap package.
• The filter that limits the extension of the files that can be uploaded.

I used a helper function to resolve the passed Url’s to absolute url’s because of some limitations I had in my library, but a simple ResolveUrl should be sufficient in most cases.

Also note the OnPluginLoaded hook. This hook is used to bind the event (that is raised when a file is uploaded) to JavaScript.

When a file upload is completed, the Silverlight component raises an event. This event is then catched by a JavaScript block which saves the token of the upload in a hidden field. The Silverlight component just displayed ‘Upload Completed’ and sits and waits until the page is submitted. (the script block is not shown here).

On postback of the page the control checks if the hidden field contains a valid token, and if this is the case, the asp.net component raises an event that can be caught by the page which contains the control.

The control implements IPostBackDataHandler, which means that on any postback the LoadPostData method of the control will be called.

The GUID of the upload is persisted in a ViewState-backed property. So even if a validation error occurs on postback, the upload is still safe. (Unfortunately, the Silverlight component does not reflect this yet). LoadPostData returns ‘true’ and the asp.net framework calls RaisePostDataChangedEvent after all the initialisation logic of the page have been completed:

The page that is subscribed to the FileUploadEvent can then call the UploadManager.GetUpload() with the ID that is provided in the event to retrieve the file.

Some tricks left

Instead of putting the SilverlightUpload.xap in /ClientBin, I have embedded the package in the web control by adding it as an embedded resource. I added this file to the project using ‘Add Existing Item’ and ‘Add as Link’ to the SilverlightUpload.xap from the web application. This last step saved me from manually copying the xap every time I created a new build.

In AssemblyInfo.cs I have added a declaration so that webresource.axd can be used to retrieve the xap:

Also, I moved the implemementation of the WCF UploadService.svc into the control DLL.

Now, to use this control:

• Add the WebResource.axd handler declaration to the web.config of your web application,
• Append the service EndPoint to the web.config,
• Add the SilverlightUpload.dll to the bin directory (or add a reference)
• Create a file that is a stub for the WCF service (this is the almost-empty UploadService.svc file),
• Create a page that uses the control,
• Add an eventhandler to the FileUploaded event

For your uploading pleasure, I’ve added the project with all code to this post.

That should be it!

SilverlightUpload.zip (73.54 kb)

Let me explain the problem. A have a server control that really needs to serious context before it can render or process postback events. The context is set using a public property mysteriously called TypeToShow. The value of the property is a complex structure and cannot be persisted in ViewState. This all works fine when I do the initial load of the page, because the CreateChildControls of the control does not occur until I call DataBind() from the containing page.

However, when a postback occurs, the CreateChildControls() method is invoked before I get a chance to inject the meta data.

I know that Asp.Net delayes all events with child controls that are dynamically added using Controls.Add(…), so my work-around was to actually use a Placeholder and create the control until Page_Load was invoked.

There is a workaround, and here it is.:

First, you need to add a couple of statements to the beginning of CreateChildControls like so:

This will case CreateChildControls to fail if the property ‘_typeToShow’ was not set. Note that in my case, my control inherits from the 2.0 CompositeDataBoundControl class that does not require you to override CreateChildControls to create your controls. Instead you need to override an overload of this method. Check the SDK on the CompositeDataBoundControl for more info.

Next, you need to give the framework another chance to fire any events. The framework calls OnLoad of the child controls after the parent has been created. This includes Page_Load. To do this, override the OnLoad of the server control like so:

The framework detects that the controls have been created and starts raising any events you may have defined.

PS. I don’t know I anyone is reading this blog (except GoogleBot). Gimme a comment!

I read an article on CodeProject about implementing the repository pattern with Linq To SQL.

I tried that approach because it sounded very nice. I did have some problems with performance and after a few debugging sessions (showing the SQL trace or the DataContext log) I found the problem.

By defining the virtual methods of the repository base class like this: public IEnumerable<T> FindAll(Func<T, bool> exp) the Func will not be (what I call) a delayed method, but it will be expanded immediately. I checked the log from the DataContext and it shows that the table is no longer queries using a where clause. Instead, a full table load is performed and the function is evaluated in memory.

However, the solution is very easy, although this mean you'll have to include the Linq assemblies to your testing bed:

protected T Single(System.Linq.Expressions.Expression<Func<T, bool>> exp)

{

    return Items.Single(exp);

}

The trick is to wrap your functions in a System.Linq expression. Client usage is exactly the same. The performance gain on my project was huge, If you consider that tables are no longer loaded completely into memory.

The full code for my repository base class is in the link below.

Repository.cs (4,64 kb)

I now have been working 12 years on software development and 8 years asp.net. I consider that to be a substational amount of experience. Because of this realisation, I'd like to share some things I've been learning of the years. I summarized my experiences, so check out this list:

1. If you find the problem, look for the answer.
2. If you find the answer, don't stop looking
3. If you stop looking, experiment. 
4. If you stop experimenting, make it work
5. If it works, redesign
6. If you're still not happy, you didn't understand the problem: back to square 1.

These are some mindblowingly simple steps. but they've always worked for me. They help, and not only in software! Number 1 and 2 are easy. That's (1) smart thinking and (2) google. We'll get to number 3 later on. The numbers 4 through 7 are simple development strategies you can read up on in tons of places.

I do like to elaborate on step 3. Most of my coworkers (and a lot of other people i meet) stop after #2. This usually happens after a couple of minutes or hours using google. By the way, if you know the problem, googling for an answer shouldn't last more than a couple of minutes. This is because google is very smart, but it doesn't know your problem. You're actually not googling for articles on the problem - you're googling for articles about the solution to that problem. This sounds strange because most articles talk about 'I have a problem with this and this', so the good google results should point you to an article or a thread that says 'I found the solution for this and this'. The trick here is to include words like 'solution' or 'best practice', 'I finally got it working' etc. to your search query.

Back to #3. Don't stop researching when you think you found the answer. To put it clearly: Number #3 is where the learning phase starts. Start working on a mind-map of the problem space. If you read enough articles on "How do I create custom controls?" for example, you usually cover a lot of the same subject matter, but if you deviate a little from the primary problem, you'll gain tons of slightly related knowledge. To illustrate, check out the class definition of a asp.net master page. I got there recently because I needed to know the base class of a MasterPage. That was easy to find - I also could've looked that up by pressing a help button in Visual Studio. I said 'for example' didn't I? Now as a case of routine I drilled down to the MasterPage Members, where I found out about two very nice properties named ContentPlaceHolders and ContentTemplates. I didn't know these existed, nor would I have found out about them in another way. Especially if you never think you'd need them. But I did need them. I had about a 100 lines of code in my application to find out what regions my MasterPage contains for a CMS i'm working on, but now I can simply refactor and clean up. The lesson I try to tell you is that browsing a couple of non-relevant links from you article *will* improve your knowledge. As you keep reading linked material you'll very soon connect some dots nobody else has ever thought about.