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!