Some thoughts about ASP.NET

When Microsoft’s .Net Framework was released back in 2002, it presented a monumental change to a lot of programming methodologies. Today, 14 years later, it’s used pretty much globally to develop anything from command-prompt tools to advanced enterprise-class cloud applications. One of the fields where .Net was particularly noticeable is developing web applications. Before .Net, programmers could use one of many languages (VB, Perl, PHP for example) and platforms (ASP, CGI etc), but one thing was in common to all of them – they were plain-text based development systems. You write your code, embedded into HTML textual files, and then drop them on a web server to run. If you need to change something you simply open the file with either your favorite development studio (or simply VI or Notepad), make the change, and click SAVE to apply the changes.

This kind of operation has limitations, of course, but it also has advantages. On one hand, it can get complicated if you manage your code using some kind of code-repository, and even more if you need to deploy it to multiple servers. On the other hand, if you need to make minor tweaks to your code quickly, this could be a very lean and mean operation.

ASP.NET, on the other hand, took classic ASP and made it into a compiled platform. You write your code in Visual Studio, compile it, and then deploy the compiled code to your server. This was a major change to the way you develop web applications. This model encourages the programmer to separate the design of the interface and the code, and is also more suitable for complex applications developed by large teams. On the other hand, it makes making minor changes to the code and re-deploying it more complex. While you can deploy your code directly to the server from within Visual Studio and other IDEs, it does make harder to make minor changes, and makes the code less portable as it requires quite an effort by other developers to edit and re-deploy the code from other computers.

Another characteristic of ASP.NET applications, which you might have noticed if you build one, is that it tends to produce a highly-inflated project. Even a blank application with a single line of code tends to produce a folder with dozens of files, using up as much as 30 MB (for example, the Roslyn folder that is created in the BIN folder). This kind of output makes it difficult for the developer or operation engineer to know which files actually need to be re-deployed in case of changes.

However, if you do dig into this, you will find out some interesting quirks of this model. The actual output of Visual Studio with a basic website depends on the version of Visual Studio you have installed. Different versions have added components that might be useless for your applications. Then again, you can’t just go in there and delete random files…or CAN you?

Well, the answer is YES…you can actually delete most of the content of the generated website, and still have a perfectly working one. One reason for sites getting bloated is the default inclusion of two NUGET packages in Visual Studio (Microsoft.CodeDom.Providers.DotNetCompilerPlatform and Microsoft.Net.Compilers). By removing these two, you can make things leaner (though you might be sacrificing some C# 6 features). To do so, click Tools/Nuget Package Manager/Package Manager Console. Then, type the following into the console:

uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform 

uninstall-package Microsoft.Net.Compilers

Once you do this and re-compile your website, you’ll find that it’s BIN folder now only contains one DLL, as well as two files that you don’t need to deploy the website.

Further to this, most of the project files that you see can also be safely avoided when deploying the project (don’t delete them from the project folder, though, as VS would need it if you do decide to rebuild it inside VS itself). Ultimately, for a basic and rudimentary website, the only files you need are:

• ·         Default.aspx
• ·         Web.config
• ·         /BIN/.dll

Another great thing to know about ASP.NET is that it’s actually backward-compatible with classic ASP. The file format can be confusing with the “code behind” statement, but having your code be “behind” isn’t actually required. If you build a blank application, you can then edit the ASPX file it produced, and place regular ASP code inside it, and it will work as-is with no special configuration either on the web server or the code itself (you don’t need to install the classic ASP component in IIS for it!). Essentially, simply place your ASP code here:

<%@ Page Language="vb" AutoEventWireup="false" CodeBehind="default.aspx.vb" Inherits="ElmahReader2._default" aspcompat="true" %>

       

   

        <%
                ###ASP Code here:

                response.write(now)

                %>

   

   

Inside the “body”, you can place any and all ASP commands, including classic ADO code to interact with SQL, or whatever it is that you need to do. If all you need to do is build a simple form or some test code, you can have a site up and running in seconds by simply dropping the ASPX and DLL files and point an IIS website at them. There’s no need to open Visual Studio, or build any projects. In fact, even if you don’t have VS at all, you simply download THIS package that I’ve build on my computer, and use it as-is….just put in your code!

The error of our ways

Software developers are typically judged by their ability to write code in one or more languages, and some of us can write in a dozen languages or even more. However, one side of writing good software that’s often missed is writing good error messages. Ultimately, any software can run into errors, whether because there’s a bug in it, or because the user made some mistake. However, a clearly written error message can make a world of difference between a minor annoyance and complete frustration that could, in some cases, lead to a piece of software being completely dropped.

A primary guidance to many developers when writing error messages is the obscurity factor. In their eyes, if the error is less likely to ever show up, they will invest little to no attention on making it useful. That’s where we run into error like these:

   

Or even better:

It’s unfortunate that developers often don’t realize the harm a bad error can do. While the internet has made it easier to find the source of obscure error messages and codes, if the error is obtuse enough, even the most experienced googler may not be able to figure it out. Googler, you ask? Well…even in corporations, where there’s a supposedly-qualified IT department that’s supposed to help with things, one must keep in mind that the typical user will start his journey with the 1^st tier helpdesk, manned by less experienced individuals. In such a case, their support individuals themselves will often turn to their favorite search engine to try to understand what’s up. In such a case, “an unknown error occurred” will make it very hard to locate the true source of the issue.

Another aspect to this is the whodunit. When a user runs into a problem, most of them need to understand whether the issue is something that they did, that was done to them, or that just happened. This is an important psychological factor because if the problem is their fault, many users may feel timid about calling out for help. On the other hand, if the problem is a result of something that was done to them (for example, if some server was disabled by the IT group, making the application cease to work), this could lead to much anger being developed and projected at that IT group. That, of course, may be well-deserved, but if it’s not, it’s the developer’s responsibility to make sure the message is clear about that.

Another aspect to be considered is the fixability. If the issue that led to the error is easily fixable…why send the user on a wild goose chase? Why not just tell him or her what to do right there? For example:

     

Finally, we already mentioned the searchability factor, and a unique message goes a long way towards that…but that also means that the message shouldn’t be TOO unique. For example, specifying the memory address in the error message may seem cool, but since it would typically be unique to every run of the app (yet is usually of no use to resolving it), it would actually make it hard or impossible to find a solution.