The other day I was posed with a problem to implement a "Send as Attachment" feature to an existing application. I thought, well this should be easy I've seen many other do it before. I quoted the work at a few hours, figuring some quick searching would give my my answers. I was wrong.

Sending an email using the default email client is very easy with the mailto: protocol. The problem lies in adding an attachment. Common mail programs like Outlook and Thunderbird do not support the attachment option. So, I started looking at MAPI the native API for doing this. I could not find any .NET wrappers. I did find that there were controls created by MS for VB6. Most of the .NET examples I found used COM interop with the ActiveX controls. But after trying these controls (which look like they were last updated in 98) I found them to not work in XP SP3. I'd get random exceptions and was never able to actually get an email dialog to pop up.

After failing with the ActiveX controls I was out of time. The MAPI native commands may have worked but it would take too long to set up the native calls and test it. After discussing with the client we ended up coming up with a bit hackish but workable solution. I would use the mailto: protocol and then launch explorer with the attachment selected. To them this is a minor annoyance that is acceptable. To me this an unfortunate sign of the times.

Things that were once "easy" for native applications become complicated and buggy for managed. It seems too often that I must make use native calls or old unsuported COM objects to get the job done. While MS has done a great job building up the .NET Framework. It seems that many native API's still remain unwrapped. Furthermore some places I read that the MAPI api is unstable on Vista. It seems that some API's are slipping through the cracks.

Ok in the last few years I've had to take over a number of websites written in VB.NET, or I should say written in VB but somehow using .NET. My issue really isn't with VB.NET itself. It's obvious the developers that did these sites (none of them affiliated in any way) came from doing classic ASP and moved onto ASP.NET. The problem is they continued with their classic ASP practices and did not seem to come close to grasping what ASP.NET really was.

Issues I've had:

• None of the sites will compile in Visual Studio
• All of the sites were running in ASP.NET 2.0 but none used master pages. They all used Server-Side Includes (which should be banned) to include common blocks.
  
• No use of controls or classes.
• No use of code-behind
• All SQL is dynamic and full of SQL Injection vulnerabilities
• All used include files which set up global variables and functions to be used in the page lifecycle (one of the main reasons the sites wont compile)
• One of the sites had every folder set up as it's own application in IIS. Their hosting provider has no interface for even seeing this, the developer used to call in to have this set up. More on this site later (refered to as BS1)
  
• Most of the sites only make use of the most basic controls
• One site (BS1) tried to use more advanced controls like Formview but failed miserably. In this instance, used all over the site, the developer made a formview, used an EditTemplate and bound a dataset to the formview. Sounds decent so far right? The issue came in after I made some changes that my data was not being updated in the dataset. Tracking down the issue was very hard to do when you have no "Go to Definition" and there are tons of "Include Files" that are copied and pasted throughout the site. I found that there was a  "Magic" function that did what databinding is supposed to do. It looked for any controls in the formview that matched the exact name of a column and bound the data.
  
• BS1 includes so many functions that recreate .NET functionality that his developer seemed to give up on getting to work within an hour or trying. I want to go home sick everytime a change comes up on this site.

Basically on every one of these sites we have pitched rewrites. Most of them on grounds of security, which is completely true. One of the sites we've had to take down due to rampant SQL Injections. It wont be up until the client decides on which overhaul to rewrite proposal they want to to sign off on.

If the BS1 rewrite ever happens I hope I am not the one to do it. While the site needs it, the business rules and database behind it are majorly complex and in some points completely bonkers. Redesigning the database will be completely out of the question due to the amount of time to migrate that and other business apps the client uses to work with it.

After all of the things I've seen I'm scared of how many classic ASP developers have moved to ASP.NET without taking the time to understand what ASP.NET (or even .NET) is all about. The thing that scares me the most is that it has been 6 years since .NET was released. Some of the sites were even written starting with ASP.NET 2.0. Yet the developers probably used Visual Studio as nothing more than a bloated notepad.

I came from doing site development in PHP 3/4. Classic ASP and PHP 3/4 development were alike in many ways. One would use server side includes to include headers/footers for the page. There would more than likely be a main include script that set up all the functions/classes and global variables to be used on the page. All the HTML was generated with inline code. I can understand moving from an environtment like that to ASP.NET you may start out recreating what you know.

What I don't understand why these developers never felt a need to move beyond that when there is overwhelming evidence that ASP.NET can do so much more. The old way is horrible to maintain, can take a long time to develop and there are much better practices out there. While I was a PHP developer I started using Smarty templates. I loved having templates that abstracted the presentation from the real code. Smarty has become one of the defacto standards in PHP development over the years. It gave me the introduction to using "controls" and "master pages". It made reuse easier and presentation cleaner. To go so long continuing the same bad practices is unfathomable to me.

Another thing that amazes me is ASP.NET actually works with server side includes. The dynamic compiler for the site will included the code and build a DLL for the page. I'm a bit pissy at MS for even allowing this. The included code is compiled into every DLL and whenever a change is made every one of those pages must be recompiled.