After a Web application is developed, it needs to be deployed to make it available as a Web site. A Web application may be made up of a number of files and components. These components may be developed by the application developer or by a third party. Therefore, while deploying a Web application, you must determine the files to be included in the deployment. In addition, you must determine the method to be used for deploying an application.
Deployment is the process of packaging all files that make up an application and distributing them for the purpose of installation on other computers. Deploying an ASP.NET application can be as easy as copying the application files to the machine on which the application needs to be deployed. When you deploy an application by copying files, no Registry entries are made. To deploy more complex applications, which may comprise various components, you may create deployment projects in Visual Studio .NET.
A deployment project enables you to specify the files to be included in the deployment, the method by which the application files will be deployed, and the location where the application is to be deployed. In this section, you will look at the different types of deployment projects, the process of creating a deployment project, adding files to the deployment project, and building the deployment project.
Choosing the type of deployment projects
Visual Studio .NET provides different types of deployment projects. The choice of a particular type of deployment project depends upon the application or the component that you want to deploy and the mode of deployment. For example, you may want to deploy an application in the form of a collection of cabinet (CAB) files for downloading the application.
The different types of deployment projects provided in Vi sual Studio .NET are as follows:
Merge module project: Creates a single package that contains all files, resources, Registry entries, and the setup logic necessary for deploying the package. A merge module is similar to a dynamic link library (DLL), which allows multiple applications to share code. The only difference in this case is that a merge module allows sharing of the setup code. A merge module project file has the extension .msm. You cannot use a merge module file by itself. You must merge the resulting .msm file with another deployment project, which creates a Windows Installer (MSI) file.
You can use a merge module project when you want to deploy a component that will be shared by multiple applications, because a merge module project identifies all the dependencies for a component and ensures that the correct versions of the components are installed. Thus, problems relating to versioning can be avoided with merge module projects. When a new version of a component needs to be deployed, you simply create a new merge module project that contains the dependencies for the new version of the component.
Setup project: Enables you to create a Windows Installer (MSI) file for deploying an application. The resulting MSI file contains the application, dependencies, information about the Registry entries to be made, and installation instructions. A setup project can be used for deploying standard Windows-based applications. When you execute the resulting MSI file, all files related to the application are copied to the Program Files directory on the target computer.
While selecting between a merge module project and a setup project, you must consider the target audience. If the application is intended for use by an end user, you should package all the files for the application in an MSI file. On the other hand, DLLs, controls, and resources that are intended for use by developers should be packaged in a merge module, which can then be packaged by the developer in an MSI file for distribution to the end user.
Web setup project: Is similar to a setup project. This type of project also results in the creation of an MSI file, which can be used for deploying an application. When you execute the MSI file, all files that make up the application are copied to the virtual root directory on the Web server.
This type of project should be used for installing a Web application on a Web server.
Cab project: Enables you to generate CAB files of a specific size. These CAB files can be used to download components to a Web browser. You can create a cabinet project if you want your component to run on the client instead of the Web server.
In addition to these types of projects, Visual Studio .NET also provides the Setup Wizard, which creates a basic setup project. It guides you through the steps of creating a deployment project. During each step, the wizard collects information, such as the files to be included in the deployment project.
User Interface Editor
When you create a deployment project, it automatically creates some dialog boxes that are displayed during the installation of the application on the target computer. The User Interface Editor displays the dialog box names and enables you to specify the properties of the dialog boxes, such as the message to be displayed in a dialog box and the name of the dialog box. In addition, the User Interface Editor enables you to add your own dialog boxes.
The User Interface Editor is divided into two sections, Install and Administrative Install. The Install section contains the dialog boxes that are displayed to the users when they start installation. The Administrative Install section contains the dialog boxes that are displayed when a network administrator moves the installer to a network location, to make it available for installation over a network.
Each section has some predefined dialog boxes, which are categorized as follows:
Start dialog boxes: Displayed to the user before the actual installation process begins. Examples of dialog boxes in this category are the Welcome screen, the dialog box that accepts customer information such as the username and company name, and the dialog box that enables a user to specify the directory in which the files are to be copied.
Progress dialog boxes: Used as a means of providing visual feedback to the user about the progress of the installation process. It typically depicts the progress in terms of the percentage of completion of the process.
End dialog boxes: Used to inform the user about the success or failure of the installation process. They also include the dialog boxes that enable you to launch the newly installed application or to restart the computer.
RELATED POST
CREATING ASSEMBLIES WITH ASP.NET
BUILDING HANDLERS IN ASP.NET
INTERFACES AND CLASSES CREATION IN ASP.NET
CACHING IN ASP.NET
CACHING IN ASP.NET PART TWO
WIRE LESS APPLICATION WITH ASP.NET
SECURITY IN ASP.NET PART ONE
SECURITY IN ASP.NET PART TWO
LOCALIZING ASP.NET APPLICATIONS
DEPLOYING ASP.NET APPLICATIONS
ASP.NET CONFIGURATION SYSTEM
WEB SERVICES IN ASP.NET
WEB SERVICES PART TWO
WEB SERVICE INFRASTRUCTURE
WEB SERVICE INFRASTRUCTURE PART TWO
EXCHANGING MESSAGES IN ASP.NET
MICROSOFT HAIL STORM
SOAP AND DOT NET PART ONE
SOAP AND DOT NET PART TWO
Deployment is the process of packaging all files that make up an application and distributing them for the purpose of installation on other computers. Deploying an ASP.NET application can be as easy as copying the application files to the machine on which the application needs to be deployed. When you deploy an application by copying files, no Registry entries are made. To deploy more complex applications, which may comprise various components, you may create deployment projects in Visual Studio .NET.
A deployment project enables you to specify the files to be included in the deployment, the method by which the application files will be deployed, and the location where the application is to be deployed. In this section, you will look at the different types of deployment projects, the process of creating a deployment project, adding files to the deployment project, and building the deployment project.
Choosing the type of deployment projects
Visual Studio .NET provides different types of deployment projects. The choice of a particular type of deployment project depends upon the application or the component that you want to deploy and the mode of deployment. For example, you may want to deploy an application in the form of a collection of cabinet (CAB) files for downloading the application.
The different types of deployment projects provided in Vi sual Studio .NET are as follows:
Merge module project: Creates a single package that contains all files, resources, Registry entries, and the setup logic necessary for deploying the package. A merge module is similar to a dynamic link library (DLL), which allows multiple applications to share code. The only difference in this case is that a merge module allows sharing of the setup code. A merge module project file has the extension .msm. You cannot use a merge module file by itself. You must merge the resulting .msm file with another deployment project, which creates a Windows Installer (MSI) file.
You can use a merge module project when you want to deploy a component that will be shared by multiple applications, because a merge module project identifies all the dependencies for a component and ensures that the correct versions of the components are installed. Thus, problems relating to versioning can be avoided with merge module projects. When a new version of a component needs to be deployed, you simply create a new merge module project that contains the dependencies for the new version of the component.
Setup project: Enables you to create a Windows Installer (MSI) file for deploying an application. The resulting MSI file contains the application, dependencies, information about the Registry entries to be made, and installation instructions. A setup project can be used for deploying standard Windows-based applications. When you execute the resulting MSI file, all files related to the application are copied to the Program Files directory on the target computer.
While selecting between a merge module project and a setup project, you must consider the target audience. If the application is intended for use by an end user, you should package all the files for the application in an MSI file. On the other hand, DLLs, controls, and resources that are intended for use by developers should be packaged in a merge module, which can then be packaged by the developer in an MSI file for distribution to the end user.
Web setup project: Is similar to a setup project. This type of project also results in the creation of an MSI file, which can be used for deploying an application. When you execute the MSI file, all files that make up the application are copied to the virtual root directory on the Web server.
This type of project should be used for installing a Web application on a Web server.
Cab project: Enables you to generate CAB files of a specific size. These CAB files can be used to download components to a Web browser. You can create a cabinet project if you want your component to run on the client instead of the Web server.
In addition to these types of projects, Visual Studio .NET also provides the Setup Wizard, which creates a basic setup project. It guides you through the steps of creating a deployment project. During each step, the wizard collects information, such as the files to be included in the deployment project.
User Interface Editor
When you create a deployment project, it automatically creates some dialog boxes that are displayed during the installation of the application on the target computer. The User Interface Editor displays the dialog box names and enables you to specify the properties of the dialog boxes, such as the message to be displayed in a dialog box and the name of the dialog box. In addition, the User Interface Editor enables you to add your own dialog boxes.
The User Interface Editor is divided into two sections, Install and Administrative Install. The Install section contains the dialog boxes that are displayed to the users when they start installation. The Administrative Install section contains the dialog boxes that are displayed when a network administrator moves the installer to a network location, to make it available for installation over a network.
Each section has some predefined dialog boxes, which are categorized as follows:
Start dialog boxes: Displayed to the user before the actual installation process begins. Examples of dialog boxes in this category are the Welcome screen, the dialog box that accepts customer information such as the username and company name, and the dialog box that enables a user to specify the directory in which the files are to be copied.
Progress dialog boxes: Used as a means of providing visual feedback to the user about the progress of the installation process. It typically depicts the progress in terms of the percentage of completion of the process.
End dialog boxes: Used to inform the user about the success or failure of the installation process. They also include the dialog boxes that enable you to launch the newly installed application or to restart the computer.
RELATED POST
CREATING ASSEMBLIES WITH ASP.NET
BUILDING HANDLERS IN ASP.NET
INTERFACES AND CLASSES CREATION IN ASP.NET
CACHING IN ASP.NET
CACHING IN ASP.NET PART TWO
WIRE LESS APPLICATION WITH ASP.NET
SECURITY IN ASP.NET PART ONE
SECURITY IN ASP.NET PART TWO
LOCALIZING ASP.NET APPLICATIONS
DEPLOYING ASP.NET APPLICATIONS
ASP.NET CONFIGURATION SYSTEM
WEB SERVICES IN ASP.NET
WEB SERVICES PART TWO
WEB SERVICE INFRASTRUCTURE
WEB SERVICE INFRASTRUCTURE PART TWO
EXCHANGING MESSAGES IN ASP.NET
MICROSOFT HAIL STORM
SOAP AND DOT NET PART ONE
SOAP AND DOT NET PART TWO
No comments:
Post a Comment