Key concepts in this chapter are:
Using various techniques to deploy applications and components
Signing applications with Authenticode and strong-name signatures
Granting applications more permissions by modifying security policy
Deploying .NET code-access security updates
Protecting your code through obfuscation
In this chapter, you’ll learn about techniques you can use to secure your Microsoft Visual Basic .NET applications and components for deployment. This includes techniques for securing your setup deployment package and the Visual Basic .NET application (and components) contained within the setup package. If you are distributing your software over a nonsecure deployment medium such as the Internet, you should take one or more of the following measures to secure your application for deployment:
Certify yourself as the publisher of the software. There should be no doubt the software was published by you and not an imposter. Later you will learn about Authenticode signing as a way of certifying yourself as the publisher of the software.
Protect your software from being modified. The integrity of your software should not be compromised in any way. You can use strong-name signing (described later) as a means of guaranteeing the integrity of your software.
Restrain your software from performing destructive actions. Your software should not be allowed to perform any destructive actions even if the software attempts to do so. In the next section, you’ll learn which deployment techniques provide the most restraint over your code by means of the .NET code-access security system.
The deployment techniques described in the next section should help you decide which of the above measures you need to take. Let’s take a look at those techniques.
You can deploy a Visual Basic .NET application or component in a number of ways, such as XCopy, no-touch, Windows Installer, or a cabinet-file installation. The Windows Installer and cabinet-file installation techniques are traditional deployment technologies that can be used for Microsoft Windows .NET and traditional Windows applications and components (such as ActiveX controls). XCopy and no-touch deployment techniques are new to Visual Basic .NET.
XCopy deployment gets its name from the command-line tool XCopy.exe. XCopy deployment is a means of recursively copying a directory containing an application (and all subdirectories contained within the directory) to a location where the application will be run. .NET makes XCopy deployment possible because .NET applications and components typically do not require any special registration—unlike ActiveX components—in order to run. If your Visual Basic .NET application is composed entirely of .NET components—or in other words, is void of ActiveX components—XCopy deployment might be an option for you. XCopy deployment generally works best for ASP.NET Web applications and Web services applications where you copy the application from the development computer to the target Web server computer. When copying a Visual Basic .NET application from one computer to another using this technique, you should preserve the following file information:
File attributes such as read-only, hidden, system, and so forth. If using XCopy.exe, use the /K option to preserve file and folder attributes, the /R option to enable replacement of read-only files (on the destination computer), and the /H option to copy hidden and system files.
Windows security-related permission ACLs for all files and folders being copied. If using XCopy.exe, use the /O option to preserve ACL permissions.
This technique involves making your Visual Basic .NET Windows Forms application or component available for direct execution from a Web page—actually the application and associated components are copied from the Internet (or intranet, depending on the location of the Web page) to a special Internet download cache on your computer, and they are run from there. Benefits of using no-touch deployment include:
A centralized deployment model is provided for Windows Forms applications and components, where all clients are automatically updated with the most recent version of the application or component deployed on a Web server.
The application or component is assigned .NET code-access security permissions based on the security zone where it was downloaded from, as described in Chapter 3.
For general information on no-touch deployment, refer to the following links:
For more information on how to deploy Windows Forms user-controls by means of no-touch deployment, refer to the following link: http://www.gotdotnet.com/team/windowsforms/iesourcing.aspx.
You can use a variety of tools, including the Microsoft Visual Studio .NET Deployment Wizard to create a Windows Installer (.MSI) deployment package. A Windows Installer package is a full-featured setup allowing you to include a user interface (UI) that allows the user to specify installation options such as the application features to install and the directory location where the application files will be installed. You should deploy your application in a Windows Installer package if your application has any of the following requirements:
Choice of features to install for the user to pick from
Application directory location determined by the user
Registration of any ActiveX or .NET components
Installation of system-style .NET .DLL components (assemblies) to the global assembly cache (GAC)
Desktop shortcuts or Start menu items
Reboot as part of installation required to replace a file in use by the operating system
Disabling a Windows operating system service required to install a component
Another use of the Windows Installer package is to bundle up .NET code-access security permissions to be distributed with your Windows Forms application. In this case, your customer first installs the security policy updates—your customer will need to be logged on as an administrator of her computer to install policy changes on it. The Windows Forms application or component requiring the security policy updates can be deployed in a separate Windows Installer .MSI file or by using the no-touch deployment technique described previously.
Cabinet files (.CAB) are typically used as a means of distributing ActiveX components on the Internet. .CAB files use the same underlying technology as Windows Installer files, but .CAB files typically don’t show any UI. If you want to include an ActiveX component on a Web page, consider using a .CAB file to deploy the component. In the case of .NET components you want to include on a Web page, you should use no-touch deployment (discussed previously) instead.
For more information on cabinet-file deployment, see the following link: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon98/html/vbconhowinternetcomponentdownloadworks.asp.
Table 10-1 provides a summary of the deployment techniques available, along with advice on when to use each one.
Table 10-1. Deployment Techniques and When to Use Them
Deployment Technique | Use When | Notes |
---|---|---|
XCopy | Application is an ASP.NET or Web service deployed to a Web server. |
|
No touch |
|
|
|
| |
Cabinet file (.CAB) | ActiveX or .NET component is deployed on Internet for use on a Web page. | If a .NET component is included in the .CAB, the deployment works much like no-touch deployment. |
3.144.172.38