Bad way to extend an ASP.NET product

How do you extend your ASP.NET product when you have no access to the source code?

First, some background: We received a customization order to add webmail-style attachments to our webapp, the kind of easy job we let our junior developers cut to their teeth on. However, the target app was developed by an ex-partner, one who've parted ways with bridges burning and much bad blood. Cutting the drama short, we didn't have the code. We could make changes to the ASPX file and the DB sprocs, but we couldn't add new code-behind and class level business logic into the app.

Of course, we could've reverse-engineered the web project and recompiled the whole thing anew with our extended functionalities. But, we went a different way. The bad way.


We used JavaScript to hack the customized features into our app. The script dynamically adds an iframe (containing the upload attachments functionality) to each target webpage. When the existing webpage's form submit event is triggered, the iframe page hijacks the client-side event handler and posts back, uploading the attachments. Each attachment is saved into a binary column on a newly created database table, and artificial keys are created on both the primary and this new table to provide referential coupling.

I'll go into the technical details in upcoming posts. What I'd like to do is discuss the rationale of our approach:

1. We minimized and isolated modifications to an unsupported piece of software.
With our ex-partners withholding support and source code, we tried not to introduce changes into software we didn't develop and can't test. The best way is to use Reflector or some other tool to reverse engineer the software and recompile it. But, a tight delivery deadline meant we didn't have the time to learn to do this (it might've taken only an afternoon for all we know), so we decided to use client-side scripting. And because we didn't hack the ASP.NET 1.1 webproject,

2. We didn't have to migrate the software to use ASP.NET 2.0's RAD controls
When the order came in, I immediately thought to use 2.0's FileUpload , DetailsView, and SqlDataSource controls. These provided a very fast way to create all the attachments functionality in one single ASPX file, with very little code. UI data-binding and database access were a breeze. Eveything worked almost right out of the box, I'd only needed custom (inline) codes for DetailsView.ItemInserting and DetailsView.ItemUpdating, plus some CSS to make the new page fit in with the look and feel of the target app.

3. Installation of the new features is a no-brainer
No need to redeploy the whole project, which would mean some system downtime. Installation would be, create a new virtual directory within the same domain (but running ASP.NET 2.0), create the new attachments DB table, and copy the attachments ASPX and JS file. We needed only one line of JavaScript added into a existing common JS file, to call our extended features script. So, this is the single one point of change in the existing software.

But, I can't help but feel that what we're doing isn't right. It's the same feeling I got when we added random client-side scripts into our other software, the same feeling that tells me this will be coming back to haunt me.

How would you have done things differently?