<%@ Page %>
Deploying .NET Applications
Once you develop and test your application, it's time to deploy it in production environment. .NET greatly simplifies the deployment process. There are no issues such as component registration and versioning problems (DLL Hell). However, still as a deployment in charge you must be aware of various deployment scenarios and how to effectively decide your deployment strategies. In this article I will take most common scenarios and explain how deployment works under each one.
Application under .NET is often called as XCOPY deployment. This is because you can deploy your applications in production environment by simply copying the folder tree (similar to XCOPY command in DOS) on the development machine.
In this article I will touch following deployment scenarios:
- Deploying ASP.NET Web Applications
- Deploying ASP.NET Web Services
- Deploying HttpHandlers and HttpModules
- Deploying Windows Forms Application
- Deploying .NET components
- Deploying COM components
In following text, when I use the word deploy it also means one of the following things:
- Copying files using windows explorer or command prompt
- Copying files using FTP
- Copying files using web based file manager interface provided by many web hosts
Deploying ASP.NET Web Applications
Deploying web applications is never been easy in past. You have to do so many tasks such as create virtual folder in IIS, set pooling model, set custom error pages and so on. ASP.NET on the other hand makes deployment very easy. There is now only one task for which you really need to sit in front of IIS - Creating Virtual Directory or Web Site. Apart from this almost all other commonly used tasks can be done via web.config file. So, try to use web.config as far as possible rather than changing settings in IIS.
ASP.NET applications consist of web form pages. Web form pages can be developed in three ways:
- Single Page: All markup and code lies in the same page with extension .aspx
- Compiled Code Behind: All markup is in .aspx page and all code (event handlers,
functions etc.) is in a 'code-behind' file (.vb or .cs). This is the default
style used by VS.NET.
- Source Code Behind: This style is same as above but instead of compiling the
code-behind into an assembly you directly attach the source code with the .aspx
file using SRC attribute in @ Page directive.
Irrespective of the coding style you use, you need to create a virtual root in
IIS on the destination web server. This task can not be done via any
configuration file etc. You need to have access to the server to do that. You
also need to create a BIN folder under this virtual root for your compiled code
(code-behind assemblies, components etc.)
Once you have IIS virtual root ready you can deploy files to the server using explorer, FTP or some web based interface provided by your web host. The way you use depends whether the destination server resides within your organization or at some remote place. If you have coded your web forms using first style then all you need to deploy at the production web server is the .aspx files. If you have used second style then you need to copy all the .aspx pages on the web server and in addition you need to copy the compiled code-behind assembly in the BIN folder. If you have adopted the third style of coding you need to deploy .aspx as well as .vb or .cs files (depending on the development language you used).
Once you deploy all the necessary 'code' files you also need to deploy web.config file(s). Make sure to change the database connection strings, file paths and web service urls (these are common candidates for storing in web.config) to match production environment.
Deploying ASP.NET Web Services
Deploying ASP.NET web services is very similar to deploying ASP.NET web applications. You have the same options as mentioned above. Only thing that changes is - instead of .aspx files you will be deploying .asmx files. As with web application be sure to modify web.config to suit the production environment.
Deploying HttpHandlers and HttpModules
HttpHandlers and HttpModules are equivalent to ISAPI Extensions and ISAPI Filters respectively. In .NET they physically exist as .DLL files. You need to FTP or copy these dlls to the web server. Once you deploy HttpHandlers and HttpModules, you need to configure them using IIS snap-in. This reqires that you have access to the web server machine.
Deploying Windows Forms Application
Deploying windows forms application is an easy matter. You simply need copy EXE and DLL files in a folder. In case you are using app.config file be sure to copy that as well. Also, make necessary changes to the app.config to suit the production environment. In addition to the EXE and configuration, you may also have resource files (resx or satellite assemblies). You also need to copy them on destination machine. Remember to create appropriate folder structure for satellite assemblies.
Deploying .NET components
If you are deploying components for a web application then you need to deploy the .DLL files in the BIN folder of the virtual root. If you are deploying for windows application (.EXE) they must reside in the same folder as the application EXE file. In some cases you may want to host your components in Global Assembly Cache (GAC). If you intend to do that, you must have access to the destination machine to invoke GACUTIL command line utility. The components hosted in GAC need not be deployed in the BIN or application folder as mentioned previously.
Deploying COM components
Many projects still rely on COM components because of reasons such as time tested functionality, reuse and existing investment. In order to consume COM components in .NET you create wrapper dlls for these components. When you deploy your .NET application you should make sure that the COM components it uses are installed on the destination machine. In addition you must also deploy the wrapper dlls along with the application. For web applications these dlls must reside in the BIN folder and for windows applications they must reside in the same folder as the executable. Be careful about the versions of COM components on development and production machines. Mismatch in versions can cause your application to give unexpected errors.
VS.NET Deployment projects
Since deployment under .NET is easy you may bypass creating setup projects or installable for your projects. This may work for small projects. But if you want to add features such as creating IIS virtual root, installation time configuration etc. you must create setup package for your application. Setup package also make your application 'professional'. VS.NET has special type of projects called Setup and Deployment Projects that allow you to bundle your application in a .msi file. You can then run this setup file on any machine on which you want to install the application. There are also third party vendors such as InstallShield that also provide software to create setup programs.
.NET makes overall application deployment very easy. However, you should be aware of certain facts need to be taken into account before designing the deployment plan. In this article I tried to cover the most commonly used scenarios of deployment and listed areas you should take care of.