VB.NET 2005 Tutorials : Creating Installation Components
In this tutorial you will learn how to Create installation components, Work with predefined Installation Components, Deploying an Assembly containing the Installation Components, Working with Installer Classes, URL Remoting, Launching a Remote Application, The Download Cache, Code Access Security Policy and Methods of Deployment
Creating installation components
Understanding the Installer Class
Installer class is the base class for all custom installers in the .NET Framework. Installers are components that assist in installing applications on a computer. The steps that must be followed to use the installer class are given below:
1. Inherit the System.Configuration.Install.Installer class
2. Override the Install, Commit, Rollback and Uninstall methods
3. Add the System.ComponentModel.RunInstallerAttribute
4. Put your derived class in the assembly with the application to Install
5. Invoke the installers. For this you can use InstallUtil.exe.
Sample code that illustrates the use of System.Configuration.Install.Installer class and creating a class that inherits form it. It also shows the method overrideing.
Click here to view sample code
Working with predefined Installation Components
When deploying an application on a computer which needs the use of a performance counter, the counter must also be installed. Using an installation component, the application can be set up so that it automatically creates and configures the necessary performance counter on a remote computer application is installed. The installation components can be of two types namely, the installer classes added to the projects, and pre-defined installation components that are associated with components.
Predefined installation components are associated on a one-to-one basis with the components that need them. For example, an instance of the MessageQueue component in the project requires that the deployed application has a queue installed and configured—the developer has to create an installation component to handle the task. Then if the developer wants to add an instance of an EventLog component to the project he has to configure the event log in use, and must add a second installation component to perform that processing.
The .NET Framework has five predefined installation components can be used in the projects. They are listed below in the table.
Installer Components and Description
EventLog installer – Allows you to install and configure a custom event log that your application needs in order to run (based on the System.Diagnostics.EventLogInstaller class)
MessageQueue installer – Allows you to install and configure a queue that your application needs in order to run. (based on the System.Messaging.MessageQueueInstaller class)
PerformanceCounter installer – Allows you to install and configure a custom performance counter that your application needs in order to run. (based on the System.Diagnostics.PerformanceCounterInstaller class)
The Service and the ServiceProcess installers – They are used together to allow you to install service applications. (based on the System.ServiceProcess.ServiceInstaller and System.ServiceProcess.ServiceProcessInstaller classes)
All of the installation components in a project are stored within classes marked with the RunInstallerAttribute=True. By default, a class named ProjectInstaller that contains this attribute is added to the project when a predefined installation component is added; installer classes added via the Add New Item dialog box also contain this attribute and are named Installer1 by default.
Adding predefined installation components to your project.
1. In the designer, click the component for which an installation component is to be added, and then click the Add Installer link in the Properties window.
2. If necessary, access the ProjectInstaller class in the Code Editor and modify any of the values that were copied to the installation component.
3. Override any methods for which need to perform custom processing.
4. Continue to perform steps 1 through 3 for each installation component the project needs.
Deploying an Assembly containing the Installation Components
Assemblies containing installation components can be deployed by using the setup and deployment projects or by using the Installer tool.
Using the Setup Project to Install Component Resources
1. Add a new setup project to the solution and give it a name.
2. Right click the project in the Solution explorer and select Add, Project Output from the menu
3. In the Add Project Output group dialog box select Primary Output of the Project.
4. Open the Customs actions editor for the project and right click the Cutoms Actions Node. Add Custom Action from the shortcut menu.
5. The select item in the Project dialog box appears.
6. In the Application folder select Primary Output from the application(Active).
7. The primary out put will be added to the four nodes under Custom Actions–Install, Commit, Rollback and Uninstall.
8. Select New Project in Solution Explorer. Activate the properties window.
9. Set the Parameters for the application.
10. Build the application and take the project’s output to a computer that does not already have an event source for the application.
11. Run the installation.
Deploying an Installation component by using the Installer tool
The command line installer tool is used to install assemblies that contain additional component tools. The resources contained in the Assembly1.dll can be installed using installutil.exe. Resources contained in multiple assemblies can also be installed using the installutil.exe. The uninstaller.exe is used to uninstall the assemblies.
Working with Installer Classes
Customized installer classes can be used to perform custom actions during installation. These compiled Installer classes from the project are added to the deployment project as custom actions that are run at the end of the installation. The process is as under:
1. Inherit a class from the installer class.
2. The RunInstaller attribute is set to true in the derived class.
3. Override the Install(), Commit(), Rollback() and Uninstall() methods to perform any custom actions.
4. In the setup project, use the Custom Actions Editor to invoke this derived class to do the required processing.
URL Remoting
The zero deployment model provided by the .NET framework for deploying Windows applications. In this model users are not required to deploy the application before executing it. They can just run the application and the application installs itself. All necessary code and configuration files are kept on a web server and users can execute the application by pointing to the URL of the.exe from Internet Explorer.
The server need not have the .NET framework installed on it. All code and configuration files are automatically downloaded form the web server and executed on the local machine. This model is exciting because it gives ease of maintenance that is available from a web application in addition to the rich user interface of Windows forms.
Launching a Remote Application
1. In the solution explorer, add Visual C# Windows application project. Give th project a name.
2. Rename form 1.cs file to the
3. Place a TextBox control, a button control and a label control on the form. Set the TextAlign property of the label control to MiddleCenter and set the font to a larger size.
4. Add the following code to the Click event handler
Private void btnDisplay_Click(Object sender,System.EvenArgs e)
{
lblMessage.Text=txtMessage.Text;
}
5. Set the project as the startup project and run the project. Enter some text in the text box and click the button.
6. Note that the text is displayed in the Label control.
7. Copy the .exe file to a Web server directory
8. Launch Internet Explorer. Navigate to http://localhost/somename.exe.
9. If the Web server is local or within an intranet zone, the application is launched. If it is through the Internet a security exception is thrown up.
The Download Cache
Downloaded code from an URL is cached in a central location called the download cache. The source information is available to the download cache and whenever a request is made for the particular URL, the cache checks the timestamp of the requested assemblies and downloads the latest version. This feature makes it extremely useful. It also isolates the assemblies from other assemblies that are downloaded by other users or applications. This cache is physically stored in a directory that is private to the user. The folders in this cache have cryptic names. To browse the contents of the cache the user has to open Windows Explorer and navigate to the assembly cache folder. The folder can be accessed by use of the command line gacutil.exe.
Code Access Security Policy
To help protect computer systems from malicious mobile code, to allow code from unknown origins to run with protection, and to help prevent trusted code from intentionally or accidentally compromising security, the .NET Framework provides a security mechanism called code access security. Code access security allows code to be trusted to varying degrees depending on where the code originates and on other aspects of the code’s identity. Code access security also enforces the varying levels of trust on code, which minimizes the amount of code that must be fully trusted in order to run. Using code access security can reduce the likelihood that the code can be misused by malicious or error-filled code. It can reduce liability because the set of operations the code can be specified. Code access security can also help minimize the damage that can result from security vulnerabilities in the code. All managed code that targets the common language runtime receives the benefits of code access security, even if that code does not make a single code access security call.
To enforce the security we establish code access security policy. The caspol tool is used to view the security policy and also to manage and configure the same.
To view the security policy with code caspol.exe:
In the command prompt window enter the command
caspol [-enterprise] [-maching] [-user | -all] –list
Caspol.exe lists the membership condition name and a membership condition value if available, followed by the name of the permission set associated with that code group. If the code group merges the permissions of its child code groups using first-match logic, Caspol.exe indicates this by displaying (FirstMatchCodeGroup) next to the code group. The default merge logic performs a union on permissions that child code groups grant.
To add an assembly that implements a custom security object to the fully trusted assembly list
Before an assembly is added to security policy, a strong name must be given to it and put in the global assembly cache.
-
Type the following command at the command prompt:
caspol [-enterprise|-machine|-user] –addfulltrust AssemblyFile -
Specify the policy-level option before the –addfulltrust option. If you omit the policy-level option, Caspol.exe lists the permission sets at the default policy level. For computer administrators, the default level is the machine policy level; for others, it is the user policy level.
-
The following command adds MyCustomPermissionSet.exe to the user policy level’s fully trusted assembly list.
caspol –user –addfulltrust MyCustomPermissionSet.exe
To view the permission sets used at a policy level
Type the following command at the command prompt:
caspol [-enterprise|-machine|-user|-all] -listpset
Specify the policy-level option before the –listpset option. If the policy-level option is omitted, Caspol.exe lists the permission sets for the default policy level. For computer administrators, the default level is the machine policy level; for others, it is the user policy level.
The following command lists the permission sets for all three policy levels.
caspol –all –listpset
To add a named permission set to a policy level
-
Type the following command at the command prompt:
caspol [-enterprise|-machine|-user] -addpset xmlFile [permissionSetName] -
Specify the policy-level option before the –addpset option. If the policy-level option is omitted, Caspol.exe adds the permission set at the default policy level. For computer administrators, the default level is the machine policy level; for others, it is the user policy level.
-
Supply a permission set name if the XML file does not contain one in the form of a name attribute value.
-
The following command imports the MyPermissions.xml permission set file as the MyPermissions permission set at the machine policy level.
caspol -machine –addpset MyPermissions.xml MyPermissions
To remove a permission set from a policy level
Type the following command at the command prompt:
caspol [-enterprise|-machine|-user] –rempset PsetName.
Specify the policy level before the –rempset option. If you omit the policy-level option, Caspol.exe removes the permission set from the default policy level. For computer administrators, the default level is the machine policy level; for others, it is the user policy level.
The following command deletes the MyFilePset permission set from the machine policy level.
caspol –machine –rempset MyFilePset
To change permission set
Type the following command at the command prompt:
caspol –chgpset pset_file pset_name.
The following command changes the FilePset permission set in the user policy to the state specified in the NewPset.xml file.
caspol –user –chgpset NewPset.xml FilePset
To list the code groups an assembly belongs to
Type the following command at the command prompt:
caspol [-enterprise|-machine|-user|-all] –resolvegroup assembly-file
Specify the policy-level option before the –resolvegroup option. If the policy-level option is omitted, Caspol.exe shows all policy levels.
The following command lists the code groups that MyAssembly.dll belongs to at the user policy level.
caspol –user –resolvegroup MyAssembly.dll
To list the permission set for an assembly
Type the following command at the command prompt:
caspol [-enterprise|-machine|-user|-all] –resolveperm assembly-file
Specify the policy-level option before the –resolveperm option. If you omit the policy-level option, Caspol.exe shows the intersection of all policy levels.
The following command requests a list of permissions that apply to MyApplication.exe at the user policy level.
caspol –user –resolveperm MyApplication.exe
To undo a policy change
Type the following command at the command prompt:
caspol [-enterprise|-machine|-user|-all] –recover
Specify the policy-level option before the –recover option. If you omit the policy-level option, Caspol.exe undoes the policy change at the default policy level. For computer administrators, the default level is the machine policy level; for others, it is the user policy level.
The following command undoes the last change to the user policy.
caspol –user –recover
To return to the default security policy settings
Type the following command at the command prompt:
caspol [-enterprise|-machine|-user|-all] –reset
Specify the policy-level option before the –reset option
The following command resets the machine policy.
caspol –machine –reset
Allow Partially Trusted Callers Attribute
Allows strong-named assemblies to be called by partially trusted code. Without this declaration, only fully trusted callers are able to use such assemblies. This class cannot be inherited. By default, a strong-named assembly that does not explicitly apply this attribute at assembly level to allow its use by partially trusted code can be called only by other assemblies that are granted full trust by security policy. This restriction is enforced by placing a
System.Security.Permissions.SecurityAction.LinkDemand for FullTrust on every public or protected
method on every publicly accessible class in the assembly. Assemblies that are intended to be called by partially trusted code can declare their intent through the use of the System.Security.AllowPartiallyTrustedCallersAttribute. The attribute is declared at the assembly level. An example of the in Visual Basic is
< assembly:AllowPartiallyTrustedCallers >
The presence of this assembly-level attribute prevents the default behavior of placing FullTrustSystem.Security.Permissions.SecurityAction.LinkDemand security checks, making the assembly callable from any other assembly (partially or fully trusted).
When this attribute is present, all other security checks function as intended, including any class-level or method-level declarative security attributes that are present. This attribute blocks only the implicit fully trusted caller demand.
This is not a declarative security attribute, but a regular attribute (it derives from System.Attribute, not System.Security.Permissions.SecurityAttribute).
Usage:
Dim allowPartiallyTrustedCallersAttribute1 As New AlowPartiallyTrustedCallersAttribute()
Methods of Deployment
There are three different strategies for deploying a ClickOnce application; the strategy that you choose depends primarily on the type of application that you are deploying.
-
Deployment via Removable Media Like CD or DVD
-
Install from the Web or a Network Share
-
Launch from the Web or a Network Share
Deployment via Removable Media
Using this strategy, the application is deployed to removable media such as a CD-ROM or DVD. As with the previous option, when the user chooses to install the application, it is installed and launched, and items are added to the Start menu and the Add / Remove Programs group in the Control Panel. This strategy works best for applications that will be deployed to users without persistent network connectivity or with low-bandwidth connections. Because the application is installed from removable media, no network connection is necessary for installation; however, network connectivity is still required for application updates.
-
To enable this deployment strategy in Visual Studio, click From a CD-ROM or DVD-ROM on the How Installed page of the Publish Wizard.
-
To enable this deployment strategy manually, edit the forwardingUrl tag in the deployment manifest.
Network-based Deployment or Web-based Deployment
Using this strategy, the application is deployed to a Web server or a network file share. When an end user wants to install the application, he clicks an icon on a Web page or double-clicks an icon on the file share. The application is then downloaded, installed, and launched on their computer. Items are added to the Start menu and the Add / Remove Programs group in the Control Panel. Since this strategy depends on network connectivity, it works best for applications that will be deployed to users who have access to a local area network or a high-speed Internet connection. To enable this deployment strategy in Visual Studio, click From the Web or From a UNC path or file share on the How Installed page of the Publish Wizard. This is the default deployment strategy.
Launch from
This strategy is similar to the first, except the application behaves like a Web application. When the user clicks a link on a Web page (or double-clicks an icon on the file share), the application is launched. When the users close the application, it is no longer available on their local computer; nothing is added to the Start menu or the Add / Remove Programs group in the Control Panel. It must be note that technically the application is downloaded and installed to an application cache on the local computer, just as a Web application is downloaded to the Web cache. As with the Web cache, the files are eventually scavenged from the application cache. The perception of the user, however, is that the application is being run from the Web or file share. This strategy works best for applications that are used infrequently — for example, an employee-benefits tool that is typically run only once a year. To enable this deployment strategy in Visual Studio, click Do not install the application on the Install or Run From Web page of the Publish Wizard. To enable this deployment strategy manually, edit the shellVisible tag in the deployment manifest.
In this lesson we have seen the different ways in which Windows Applications can be deployed. We have also seen how the thinking on deployment has evolved over the different versions of VS.NET. The ClickOnce feature that has been introduced by VB.NET 2.0 is a natural evolution of the process.
