10 Tips for Shrink-wrapping ASP.NET Applications

Tuesday, September 11, 2007

Most server-side applications run on machines under our control. We know what the application's environment will look like long before deployment.

Building and packaging an ASP.NET application to deploy inside of any corporate firewall is a bit more challenging. Here are a few lessons I've learned from five years of building a commercial web app.

  1. Document your required configuration. Use this document in the sales cycle and again before delivering the software to make sure there are no surprises.
  2. Verify the environment. Even though your document says you require SQL 2005 SP2, someone will point your software to a server with SQL Server 7.0. Small mistakes like this can eat up a surprising amount of time. Write some software that will verify versions, service packs, CPU, memory, and other environmental requirements.
  3. Two words: least privilege. In today's world, someone will challenge you over all privileges you request. You need to be in the db_creator role? Why? You need to do what on our Active Directory? Why? It's best to clearly document these required privileges and explain how you use them.
  4. Look at the licensing of third party components before looking at the feature list. As soon as you find the perfect grid control, you'll find it's too expensive to deploy. Many of the commercial controls and components you can buy for server-side software are geared less towards redistribution and more towards "per server" or "per CPU" licensing.
  5. Be creative about getting diagnostics. Log errors to help debug problems, but don't count on using the event log as it may not be well maintained. The file system is generally more reliable, and many logging components offer rolling log file options. To be proactive, consider sending diagnostic information directly back to your company – just don't use email. In my experience, sending email from a web server inside the firewall out over the Internet is only going to work about 30% of the time – corporate IT departments are just too leery. Consider hosting a web service at your place that the web app can contact over port 80, but be prepared to use a proxy server.
  6. Create and install a database maintenance plan. No one else will.
  7. Ruthlessly automate the installation. Every manual step in the installation is a problem waiting to happen.
  8. Be wary of virus scanners. Many corporate departments require them, but unfortunately, they can do some funky stuff to an ASP.NET application - frequent restarts and lock assemblies. Try to impress on the new owners of your application that they can exclude your directories from scanning.
  9. Be wary of impersonation. Let's say you need access to a network resource, so you place the encrypted username and password of a domain account into web.config. At runtime, you use the credentials to impersonate a domain account and reach the resource. This strategy will work well for about three months, then that corporate password change policy is enforced, and your application starts throwing mysterious errors.
  10. Stay out of the default AppPool in IIS6. Because you don't know who your neighbors are going to be. They might like to stay up late, use too much memory, play loud music, and run with a different version of the CLR.

Comments
John Tuesday, September 11, 2007
Awesome List! Everyone of these I'm sure comes with a painful experience.
John.
Diago Tuesday, September 11, 2007
Brilliant Breakdown. Think I might use this as reference material in a community talk regarding the common mistakes developers make.

Well written!
Mike Tuesday, September 11, 2007
This is great. One question...in lieu of #9, impersonation, what would you recommend apart from using the web root as a file server? What other strategies have you used to get around that?
Mike
JD Tuesday, September 11, 2007
You can see that the list is derived from real life experience. Very useful. Thanks.

scott Tuesday, September 11, 2007
Mike:

One option is to run the web app using a domain account. This really works well in many cases. Its subject to the same problem as impersonation (someone can lock out the domain account), but at least in that case the web app wont run and it is clearly a problem in the enviornment, and not a problem in your app.

I still use impersonation in several cases, but you have to write the code assuming impersonation can fail and provide appropriate error messages so someone will know what the problem is without debugging or calling support.

John Walker Saturday, September 15, 2007
As someone who sells a shrink-wrapped ASP.NET app, I can vouch for all of these recommendations. Great stuff.

The virus scanner point recently bit me. Our app sends out emails using the System.Net.Mail namespace. Seems many virus scanners block all outgoing traffic on Port 25. This is tough to diagnose. Something to look for if your email functionality doesn't seem to be working.
gravatar r4i Friday, December 4, 2009
that tips are really awesome.I am beginner is .net developer.it helps me to improve my develop skills.thanks for sharing this tips with us,
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!