ASP.NET WebForms are NOT Being Overthrown by MVC

It’s always a fun day when the man himself, ScottGu responds to my email.  Basically it all started last week at Techdays in Toronto (pictures to follow, I promise). 

Quite a few people asked me about MVC, and whether or not it will replace Web Forms.  My response was that it wouldn’t, but I didn’t have any tangible proof.  I discussed new features in .NET 4.0, and how the development is still going strong for future releases.  Some didn’t buy it.

So, earlier today I emailed Scott and asked him for proof.  This was his response:

Hi Steve,

Web Forms is definitely not going away – we are making substantial improvements to it with ASP.NET 4.0 (I’m doing a blog series on some of the improvements now).  ASP.NET MVC provides another option people can use for their UI layer – but it is simply an option, not a replacement.

In terms of the dev team size, the number of people on the ASP.NET team working on WebForms and MVC is actually about equal.  All of the core infrastructure investments (security, caching, config, deployment, etc) also apply equally to both.

Now, MVC is new.  MVC is powerful.  MVC is pretty freakin cool in what it can do.  But it won’t replace WebForms.  Frankly, I like WebForms.  MVC does have it’s place though.  I can see a lot benefits to using it.  It alleviates a lot of boilerplate code in certain development architectures, and that is never a bad thing.

Long Live WebForms!

ASP.NET Application Deployment Best Practices – Part 2

In my previous post I started a list of best practices that should be followed for deploying applications to production systems.  This is continuation of that post.

• Create new Virtual Application in IIS

Right-click [website app will live in] > Create Application

Creating a new application provides each ASP.NET application its own sandbox environment. The benefit to this is that site resources do not get shared between applications. It is a requirement for all new web applications written in ASP.NET.

• Create a new application pool for Virtual App
  • Right click on Application Pools and select Add Application Pool
  • Define name: “apAppName” - ‘ap’ followed by the Application Name
  • Set Framework version to 2.0
  • Set the Managed Pipeline mode: Most applications should use the default setting

An application pool is a distinct process running on the web server. It segregates processes and system resources in an attempt to prevent errant web applications from allocating all system resources. It also prevents any nasty application crashes from taking the entire website down. It is also necessary for creating distinct security contexts for applications. Setting this up is essential for high availability.

• Set the memory limit for application pool

There is a finite amount of available resources on the web servers. We do not want any one application to allocate them all. Setting a reasonable max per application lets the core website run comfortably and allows for many applications to run at any given time. If it is a small lightweight application, the max limit could be set lower.

• Create and appropriately use an app_Offline.htm file

Friendlier than an ASP.NET exception screen (aka the Yellow Screen of Death)

If this file exists it will automatically stop all traffic into a web application. Aptly named, it is best used when server updates occur that might take the application down for an extended period of time. It should be stylized to conform to the application style. Best practice is to keep the file in the root directory of the application renamed to app_Online.htm, that way it can easily be found if an emergency update were to occur.

• Don’t use the Default Website instance
  • This should be disabled by default
  • Either create a new website instance or create a Virtual Application under existing website instance

Numerous vulnerabilities in the wild make certain assumptions that the default website instance is used, which creates reasonably predictable attack vectors given that default properties exist. If we disable this instance and create new instances it will mitigate a number of attacks immediately.

• Create two Build Profiles
  • One for development/testing
  • One for production

Using two build profiles is very handy for managing configuration settings such as connection strings and application keys. It lessens the manageability issues associated with developing web applications remotely. This is not a necessity, though it does make development easier.

• Don’t use the wwwroot folder to host web apps

Define a root folder for all web applications other than wwwroot

As with the previous comment, there are vulnerabilities that use the default wwwroot folder as an attack vector. A simple mitigation to this is to move the root folders for websites to another location, preferably on a different disk than the Operating System.

These two lists sum up what I believe to be a substantial set of best practices for application deployments.  The intent was not to create a list of best development best practices, or which development model to follow, but as an aid in strictly deployment.  It should be left to you or your department to define development models.

ASP.NET Application Deployment Best Practices – Part 1

Over the last few months I have been collecting best practices for deploying ASP.NET applications to production.  The intent was to create a document that described the necessary steps needed to deploy consistent, reliable, secure applications that are easily maintainable for administrators.  The result was an 11 page document.  I would like to take a couple excerpts from it and essentially list what I believe to be key requirements for production applications.

The key is consistency.

• Generate new encryption keys

The benefit to doing this is that internal hashing and encrypting schemes use different keys between applications. If an application is compromised, the private keys that can get recovered will have no effect on other applications. This is most important in applications that use Forms Authentication such as the member’s section. This Key Generator app is using built-in .NET key generation code in the RNGCryptoServiceProvider.

• Version and give Assemblies Strong Names

Use AssemblyInfo.cs file:

[assembly: AssemblyTitle("NameSpace.Based.AssemblyTitle")]
[assembly: AssemblyDescription("This is My Awesome Assembly…")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("My Awesome Company")]
[assembly: AssemblyProduct("ApplicationName")]
[assembly: AssemblyCopyright("Copyright © 2009")]
[assembly: AssemblyTrademark("TM Application Name")]
[assembly: AssemblyCulture("en-CA")]

Strong names and versioning is the backbone of .NET assemblies. It helps distinguish between different versions of assemblies, and provides copyright attributes to code we have written internally. This is especially helpful if we decide to sell any of our applications.

• Deploy Shared Assemblies to the GAC
• Assemblies such as common controls
• gacutil.exe -I "g:\dev\published\myApp\bin\myAssembly.dll"

If any assemblies are created that get used across multiple applications they should be deployed to the GAC (Global Assembly Cache). Examples of this could be Data Access Layers, or common controls such as the Telerik controls. The benefit to doing this is that we will not have multiple copies of the same DLL in different applications. A requirement of doing this is that the assembly must be signed and use a multipart name.

• Pre-Compile Site: [In Visual Studio] Build > Publish Web Site

Any application that is in production should be running in a compiled state. What this means is that any application should not have any code-behind files or App_Code class files on the servers. This will limit damage if our servers are compromised, as the attacker will not be able to modify the source.

• Encrypt SQL Connections and Connection Strings

Encrypt SQL Connection Strings

Aspnet_regiis.exe -pe connectionStrings -site myWebSite -app /myWebApp

Encrypt SQL Connections

Add ‘Encrypt=True’ to all connection strings before encrypting

• Force encryption on SQL Server protocol configurations: http://www.syfuhs.net/article/38.aspx

SQL Connections contain sensitive data such as username/password combinations for access to database servers. These connection strings are stored in web.config files which are stored in plain-text on the server. If malicious users access these files they will have credentials to access the servers. Encrypting the strings will prevent the ability to read the config section.

However, encrypting the connection string is only half of the issue. SQL transactions are transmitted across the network in plain-text. Sensitive data could be acquired if a network sniffer was running on a compromised web server. SQL Connections should also be encrypted using SSL Certificates.

• Use key file generated by Strong Name Tool:

C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\sn.exe

“sn.exe -k g:\dev\path\to\app\myAppKey.snk”

Signing an assembly provides validation that the code is ours. It will also allow for GAC deployment by giving the assembly a signature. The key file should be unique to each application, and should be kept in a secure location.

• Set retail=”true” in machine.config

<configuration>

<system.web>

<deployment retail="true"/>

</system.web>

</configuration>

In a production environment applications do not want to show exception errors or trace messages. Setting the retail property to true is simple way to turn off debugging, tracing, and force the application to use friendly error pages.

In part 2 I continue my post on more best practices for deployment to a production environment.

Stop Complaining About Software Expenses

It’s been a long week, and it’s only Monday.  It all started with an off-the-cuff comment.  It was of the petty nature, and it certainly wasn’t accurate.  It seems that is usually the case with petty comments.

I was berated for suggesting SharePoint Services as a replacement for our ageing intranet, and the commenter responded with a quick “SharePoint?  Microsoft makes that, it’ll cost too much.  Our current java site works just fine, and it’s free.”  Or something of that nature. 

How do you respond to a petty comment?  It’s pretty damn hard:

1. While Microsoft Office SharePoint Server 2007 does cost money for licensing, Windows SharePoint Services 3.0 (which MOSS is built on) is free.  Not free as in speech, but free as in beer.  Always has been. 
2. Java is a terrible language for websites.  It’s slow, and none of the developers in the company know Java.  We all program with .NET languages.
3. The current intranet is running on an AS/400.
4. The bulk of the stuff we do on our current intranet could very easily be done in SharePoint, without any development.  And, we can also increase productivity with the added features of team workspaces and free templates for other departments.
5. The only cost will be in man-hours setting the server up, and migrating content.

Those have been my main arguments since I started working here.  We are a Microsoft shop, but very often choose non-Microsoft products.  Hmm…

The main reason we don’t use Microsoft products is cost.  Plain and simple.  Ironically, that is also the same reason WHY we use Microsoft products.

We use SQL Server, Windows Server 2008, Active Directory (finally!), IIS, MOSS (soon), and program in C#.  We don’t use office 2007, only Office 2003, some computers are still on Windows 2000 and XP.  Only one computer is running Vista, and two are running Windows 7.  But then again, we are a Not-For-Profit company.  Budgets are tight.

This post is NOT a comment on our current state of technology, because like I said in a previous post, we do a pretty good job of staying on the cutting edge in a few cases.

This post IS a comment on the people out there who think cost is the only thing to look at when evaluating a product.  For the love of god, STOP bitching about price.  START bitching about quality.

I can’t stand bad software.  People don’t pay for good software, but then complain about its quality.  Come on!  There is a formula out there that calculates the cost of a piece of software over time.  It takes into account initial cost, and the cost of the updates that follow.  It’s a simple y = mx+b formula.

Now, when you have a higher initial cost, you tend to assume it’s of higher quality.  Put this into the equation, and the number of updates, and the cost to implement these updates goes down.  Over the life of the product, it’s cheaper to go with the software that is initially more expensive.  This is basic business.

What this basic business formula doesn’t show you is the added headaches you get with crappy software.  You tend to end up with silos of systems, and silos of data.  You don’t get integration.  This is where the cost sky rockets.  Or more accurately, this is where productivity decreases.

Ironically…

SharePoint Services 3.0 is free.  It doesn’t cost anything to use.  It’s easy to use, and integrates with most of our internal systems.  I just ruined my entire argument.  Sorta.  SharePoint is a quality piece of software, and over time, it will cost less to use and maintain than any of the other intranet/middleware applications out there.  Most people don’t realize this.

I’ll probably get flack for this one:  Most people don’t complain about software expenses.  They complain about Microsoft expenses.

• “We give Microsoft too much money, and don’t get enough in return.”
• “There must be better software vendors out there than Microsoft that are cheaper.”
• “Why bother upgrading; XP Works fine.”

Have you seen the cost of a friggen Oracle license?  What about IBM’s iSeries?  Novell’s Groupwise?  My jaw dropped when I saw the cost of these things.  I can’t say a single nice thing about Groupwise.  It’s a terrible product.  IBM’s iSeries is pretty good, but it’s limited what you can do with it.  Oracle knows databases, but has a higher license cost than a good chunk of a department’s salary.

Microsoft gets most of our money because it has quality products, at a good price.  Look at a few competing vendors products and compare cost and quality as well as the ability to integrate across platforms.  Revelation is a wonderful thing.  You might think twice before settling on cost.

Presenting at Techdays 2009!

Still working out session details, but it looks like I will be presenting in Ottawa and Montreal for Techdays 2009.  I will be loitering around at the Toronto event soaking up all the techie-goodness, so come find me at any of the three events.  We can talk shop, shoot the breeze, or just mill about having a good time.

I promise I won’t embarrass anyone.  Except maybe myself.  But that’s a warning for all occasions.

Here are the dates of the events across Canada.  Buy your tickets before the early-bird deal runs out!

The Early Bird price is $299.  The regular Price is $599.

I will post more on the sessions I will be presenting at a later date when I get the full details.

See you there!

Poor Quebec, This is Terrible

Microsoft certainly isn’t to blame here, it’s a law in Quebec that prevents contests from happening.  Better chance for me to win it though!

User Interface Failure, Succeeding

It’s not everyday an application interface is designed to purposefully confuse people.  It mostly just kinda happens.  There isn’t any malicious intent involved.  However, I’ve had it with Adobe and Google. 

First off, let me say that I am very disappointed in Adobe for keeping Shockwave alive.  Merge it with Flash.  Keep it down to one browser plug-in, jeez.

Second, shame on both companies for purposefully designing a confusing interface.  I visited a site recently that had a Shockwave applet.  I wanted to see it, so I installed the plug-in.  Boom, up pops this window:

I read it as this: “Hey, you just started the installation of a plug-in.  Click next to continue.”  Whereas it actually said “installing plug-in.  To install another plug-in you didn’t ask for, click next.”  The insidiousness is in the form of a little checkbox that asks if you want the toolbar.  The problem is that the checkbox looks like its part of the feature list, so naturally you just click next to continue installing the original plug-in.

It’s a nicely designed form.  It conveys information perfectly.  Except the information tricks you.  It’s very malware-y.  I would expect such a thing from Adobe; they are starting to really annoy me.  But Google has always had the mantra of “do no evil”.  I called phooey on that long ago, and this is a perfect example of their hypocrisy.  I realize they play a very minor role in this situation, but they really should have rules about how people agree to install their software.

I spent a good chunk of my morning yesterday listening to someone complain about how Microsoft installs the .NET remote app installer plug-in into Firefox, and how inappropriate that is.  In my opinion, this is way worse.  Microsoft just did it.  This is explicitly malicious.  They go out of their way to confuse you so they can say “hey, you agreed to install it.”  Phooey, indeed.

</rant>

Techdays 2009 &amp;ndash; VIP Pricing

As budgets get tighter, Tech·Days is the perfect way to get the Tech·Ed experience without the travel expense, with two days of skill-strengthening education to help you position yourself for success by:

• Learning the technology—with a customizable agenda from over forty sessions across five technical tracks on both current technologies and new products, like Windows® 7 and Microsoft® Exchange 2010;
• Connecting with Experts and Peers—with Birds-of-a-Feather lunches and the new Windows 7 Zone, you'll have lots of opportunities to share your ideas with those who know the products best; and
• Apply what you learn—with a Learning Kit packed with products and resources so you can continue to grow your skills long after the event has finished.

Technologies discussed: Windows 7 Operating System, Windows Server® 2008 R2 operating system, Visual Studio® 2008 development system, Silverlight™ browser plug-in, Exchange 2010, Security/Management, and more.

If you want the VIP Discount use the promo code TD09Partner.

Early Bird: $299, Regular Price: $599

There is a good chance I will be presenting at one (or more) of these locations, so keep an eye out.  In the event that I don’t, I will definitely be enjoying the Toronto stop of the tour.  In either case, I will be there ready to learn, with a pocket-full of business cards.

Oh, and I’ll be leaving with a box/bag/shopping cart* of swag.

*Metaphorical shopping cart.  They are going to give away lots of awesome stuff.

Security, Architecture, and Common Sense

Good enough is sometimes not good enough.  I’ve been doing a lot of thinking lately (well, I’m always thinking), and security has been an issue that has come up a lot.  Frankly, I’m a two-bit software developer.  I know my code isn’t the best, nor the most secure.  I use strong passwords, encrypt my sensitive data, and try to limit access to the applications for those who need to use it.

In theory this works.  Problem is, it’s a lame theory.  There are so many unknown factors that have to be taken into account.  Often times they aren’t.

When I go to build an application I spend time designing it and architecting it.  This is usually the case for most developers.  What I’ve noticed though, is that I don’t spend time securing it.  I can’t.

Imagine building a house.  You put locks on the doors, bars on the windows, and someone breaks in.  Why?  Because someone left the key in the door.  You can’t build against that.  You just can’t.

You can follow the Security Development Lifecycle, which I recommend to each every single developer I meet.  There are tons of resources available.  But it can only go so far.  It’s designed more for being part of the iterative processes, not the architecture.  Or at least, that’s how most people interpret it.

So?

My last post talked about Single Sign-On (SSO).  It’s a great sellable feature for any product.  What most people don’t realize though is the inherent security benefit to it.  With it, that means one less password to remember, one less password that could get intercepted, one less password to change every month.  This is a fundamental architectural issue.  But at the same time, it’s common sense.

What is sometimes the simplest idea, is usually the correct solution

What the hell does that mean?  It means keep it simple.  Security is simple.  Keep data from prying eyes, and keep it from getting lost.  This is common sense.

Security is not difficult to comprehend.  It becomes difficult when academics get involved.  Spouting theories and methodologies scares people into thinking security is extremely difficult to implement.  It’s not!

Follow the Data

Understanding the flow of data is crucial in properly architecting an application.  It’s crucial in properly securing an application as well.  SSO is a perfect example of this.

The SSO feature in Office SharePoint Server 2007 maps user credentials to back-end data systems. Using SSO, you can access data from server computers and services that are external to Office SharePoint Server 2007. From within Office SharePoint Server 2007 Web Parts, you can view, create, and change this data. The SSO feature ensures that:

• User credentials are managed securely.

• User permission levels that are configured on the external data source are enforced.

It makes perfect sense.  It’s simple when you think about, and it affects every subsystem of SharePoint.  Make security a feature.

Resources from the SQL 2008 Spatial Data Presentation

Here is the presentation.  Click the screen shot to download a ZIP of the demo and slide deck.