Addressing Common Deployment Issues
Deploying an enterprise application introduces a different set of issues from deploying typical desktop applications. Enterprise applications need to be more aware of their target environments. This typically translates into lots of launch conditions and careful attention to redistributing system files.
Deploying the .NET Framework
Every application built upon the .NET Framework will require it to be installed on the target computer. You can deploy the .NET Framework to the most recent versions of the Windows operating system, as outlined in Table 14-1.
| SUPPORTED PLATFORM | REQUIRED SERVICE PACK |
|---|---|
| Windows 98 | |
| Windows Millennium Edition | |
| Windows NT 4.0 | Service Pack 6 |
| Windows 2000 | Service Pack 2 |
| Windows XP Home/Professional |
Although all deployment projects include a launch condition to check for the presence of the .NET Framework, they do not actually install it. To quietly install the .NET Framework onto a target computer, you must invoke a special Setup.exe bootstrap application. Install the compiled sample bootstrap locally after downloading it from the Microsoft Developer Network (MSDN) at http://msdn.microsoft.com/downloads/sample.asp?url=/msdn-files/027/001/830/msdncompositedoc.xml .
Next, replace the Setup.exe bootstrap and Setup.ini file that Visual Studio provides in the deployment project's output directory with the version downloaded from MSDN. Edit the replacing Setup.ini file and set the Msi property to identify the installation package to invoke after installing the .NET Framework. Also, set the FxInstallerPath property to point to the actual binary file containing the redistributable .NET Framework:
[Bootstrap] Msi=IssueTrackerSetup.msi FxInstallerPath=redist/
For a basic English installation of any .NET application, an application's final distribution CD image should contain the files outlined in Table 14-2.
| FILE | DESCRIPTION |
|---|---|
| Setup.exe | The downloaded bootstrap startup program that checks for the .NET Framework and installs if not present |
| Settings.ini | The initialization file indicating the application deployment package and .NET redistribution package |
| MyApplication.msi | The packaged application file created by the deployment project |
| redist\dotnetfx.exe | The .NET Framework redistributable files |
Deploying the Data Access Components
Any application that implements the .NET Framework data services will also require the Microsoft Data Access Components (MDAC) library version 2.6 installed on the target computer. Deployment projects containing a data-driven application will need to create a launch condition that detects if MDAC is installed.
In the deployment Launch Conditions Editor, select the Search Target Machine node and choose Add Registry Search from its context menu. Edit the Root property to point to vsdrrHKLM. Set the RegKey property to point to Software\Microsoft\DataAccess. Set the Value property to FullInstallVer and the Property property to MDAC_SEARCH. Next, select the Launch Conditions node and choose Add Launch Condition from its context menu. Set the Condition property to MDAC_SEARCH >= "2.6". The version number is in quotation marks because the Registry key is typed as a string.
During installation, this launch condition will check the Registry path to determine if an MDAC library greater than version 2.6 is installed. If so, the installation completes normally; otherwise , the user is notified and instructed to download the package, and the entire installation rolls back to its original state.
Determining the Presence of IIS
Web applications have an additional dependency upon IIS being present. You can add a launch condition to check the Registry for the presence of IIS as well as its version.
In the deployment Launch Conditions Editor, select the Search Target Machine node and choose Add Registry Search from its context menu. Edit the Root property to point to vsdrrHKLM. Set the RegKey property to point to Software\Microsoft\InetStp. Set the Value property to MajorVersion and the Property property to IIS_SEARCH. Next, select the Launch Conditions node and choose Add Launch Condition from its context menu. Set the Condition property to IIS_SEARCH >= "5".
During installation, this launch condition will check the Registry path to determine if the IIS Web server version is greater than or equal to 5. If so, the installation completes normally; otherwise, the user is notified and instructed to install the later version, and the entire installation rolls back to its original state.
Localizing Application Deployment
You need to be aware of two aspects of localized deployment: the localized contents of the distribution and the localized version of the setup program. To create a localized version of the setup program, you need to create a new deployment project that targets the specific local. It is not possible for a single setup application to render itself differently for each local. To create a deployment project for Germany, open the deployment User Interface Editor and set the Localization property to German. Also, you will need to manually translate each custom message in every user interface dialog box into German. Although Visual Studio continues to represent the user interface in English, the resulting dialog boxes will appear in German, as shown in Figure 14-15.
Figure 14-15: A German localized version of the setup program
Another aspect of localized deployment is the distribution contents. Ideally, core application files should be locale independent and can therefore be packaged into a single merge module. You can package the remaining application files that contain locale specific code or resources separately. Ideally, identify the locale within the merge module name , such as images_german.msm.
For localized installers , you need to replace the default dotnetfxredist_x86.msm file with a .NET Framework merge module for the target locale, such as dotnetfxredist_x86_de.msm. You can obtain localized merge modules from Microsoft at http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/msdn-files/027/000/976/msdncompositedoc.xml .
Configuring a SQL Server Database
One of the most important aspects of enterprise application deployment is the proper configuration of the application's database. Many enterprise applications treat this process as a secondary step after installation. Once completing an installation, a database administrator must create a database and execute a series of SQL statements that build the database schema.
The Windows Installer provides a better option through its extensibility features. In the IssueTracker application, you can create a custom user interface form, DatabaseSetupForm, in an extended class library package. You can code this form to read an .sql script file and create the entire database schema from a custom action defined within the deployment project.
Begin by adding a new Class Library project to the solution, named DatabaseSetup . Next, select the new project and choose Add ˜ Add New Item from its context menu. Select the Installer Class template and create an instance named DatabaseSetup , as shown in Figure 14-16.
Figure 14-16: Adding a new installer class to the project
The new DatabaseSetup class will serve as the entry point for the Windows Installer into the assembly. Listing 14-1 adds the necessary implementation to respond to the Windows Installer and activate a user entry form.
 |
[RunInstaller(true)] public class DatabaseSetup : System.Configuration.Install.Installer { DatabaseSetupForm formDatabase = new DatabaseSetupForm(); private System.ComponentModel.Container components = null; public DatabaseSetup() { InitializeComponent(); } private void InitializeComponent() { components = new System.ComponentModel.Container(); } public override void Install(IDictionary savedState) { base.Install (savedState); formDatabase.ShowDialog(); } public override void Commit(IDictionary savedState) { base.Commit (savedState); formDatabase.ShowDialog(); } } | |
The installer class derives from the System.Configuration.Install.Installer object, which manages the interaction with the Windows Installer. Two methods are overridden, Install and Commit. Both methods represent possibly entry points into the object, depending upon which custom action node activates the object. In either case, a new form, DatabaseSetupForm, displays.
Next, you need to create the new form to capture input from the user. Select the DatabaseSetup project and choose Add ˜ Add Windows Form from its context menu and set its name to DatabaseSetupForm.cs. This creates a blank Windows form, which in turn automatically creates references to the System.Forms and System.Drawing namespaces. Add form controls that capture the database server name, login name, and password, as shown in Figure 14-17.
Figure 14-17: Creating a custom form to capture additional setup information
After creating the dialog form, you need to implement the Setup button handler to read an .sql script file and execute its table creation commands. Listing 14-2 implements the button handler that takes the server configuration settings, connects to the database, and creates the complete application schema.
| |
private void btnSetup_OnClick(object sender, System.EventArgs e) { SqlConnection sqlConnection = new SqlConnection(); try { //format the connection string string strConnString = "server=" + txtServer.Text + ";uid=" + txtLogin.Text + ";pwd=" + txtPassword.Text; //create the new database sqlConnection.ConnectionString = strConnString; sqlConnection.Open(); sqlConnection.ChangeDatabase( "master" ); SqlCommand sqlCommand = new SqlCommand( "CREATE DATABASE " + "IssueTracker", sqlConnection ); sqlCommand.ExecuteNonQuery(); //read the sql sourcefile Assembly assembly = Assembly.GetExecutingAssembly(); string strAssemblyPath = assembly.GetName().Name + ".CreateDatabase.sql"; Stream stream = assembly.GetManifestResourceStream( strAssemblyPath ); StreamReader reader = new StreamReader( stream ); //execute table create sql file sqlConnection.ChangeDatabase( "IssueTracker" ); sqlCommand = new SqlCommand( reader.ReadToEnd(), sqlConnection ); sqlCommand.ExecuteNonQuery(); MessageBox.Show( "IssueTracker database setup complete.", "Succeess" ); } catch( SqlException x ) { MessageBox.Show( x.Message, "Database Setup Failed" ); } finally { sqlConnection.Close(); } return; } | |
This method begins by building a connection string from the user entry fields and opening a connection the database. Next, the connection points to the master table where the first SQL statement can create the IssueTracker database using the ExecuteNonQuery method. Next, the method obtains information about its assembly and retrieves the embedded .sql file for reading. Next, the connection points to the newly created database where the SQL statements within the embedded .sql file can be executed, again using the ExecuteNonQuery method.
The last step in the process is to create the SQL file. A new text file, CreateDatabase.sql, is created and added to the project with its Build Action property set to Embedded Resource. Appendix A, "Building the IssueTracker Database," outlines the SQL statements that create the application's data and validation tables.
EAN: 2147483647
Pages: 119