10 Tips for Shrink-wrapping ASP.NET Applications

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.