Creating Setup and Deployment Projects in VS.NET

Pocket PCs which run Windows CE 3.0, a version of Windows, is designed to be as compact and modular as possible. As a result, not all the features you've come to expect on a Windows PC are present - but a surprising number are available, including the Windows Script engines. JScript and Visual Basic Scripting Edition (VBScript) are available on all Pocket PCs to provide access to the script engines in applications such as Pocket Internet Explorer .

Pocket PC ships with a version of Internet Explorer, affectionately known as PIE (Pocket Internet Explorer). PIE has a bunch of interesting features, one of which is the ability to run script code in an HTML page. Because memory is at a premium on Pocket PCs, PIE allows only one
This step-by-step tutorial guides you how to create a setup and deployment project using Visual Studio .NET to build a setup of your applications. 

Even before we could get into the VS.NET mode of creating setups we will have a quick introduction on the need of automated setups.

Section I: Introduction

I-1: Why?

The First Question I would like to ask the development community is how many among us use a proper installer for deployment. The answer could well be very few since many would prefer the manual way of installation. Many teams overlook the need for proper automated installation; reason could well be no time allocation for the team to come up with automated installation plans. I can assure that one can reduce around 30-40% of post-installation issues if you plan for a proper automated installer. We will look on how to troubleshoot the origin of these issues in the next section.

I-2: Deployment Plans?

There are many topics that have to be thought about before releasing a plan for process of installation. Some of the critical questions to these issues are as follows:

Q: a) What do you want to deploy? Is it a Web application files setup, Client Desktop
Setup or a Database installation?

Q: b) What are the pre-installation Harware configuration i.e processor settings,
RAM, disk space etc; Software packages i.e MS Office, SQL Server Enterprise edition, etc that are mandatory for you to setup?

Q: c) Which are the physical paths for your custom files, system files, Database (.dat,
mdf etc), configuration files, read-write files? This is critical today since for us to be Windows 2003 compliant there are certain rules that have to be followed in this regard.

Q: d) What do you want to configure post-installation? These may include things like
configuring database connection string in your Web.config files; register the user via web by running a custom exe file etc.

Answers to the above points lead us to a sketchy definition of our deployment plan in general. If you were to analyze and answer the above points as a checklist;
For e.g.

Answer: a) Web Application
I need to figure out an installer that can set up webprojects. This will be my INSTALLER PROJECT TYPE.

Answer: b) Intel Pentium 566 Mhz, 256 MB RAM, 9 Gb HDD; Windows 2000 Enterprise edition, MS Office 2000, SQL Server 2000, MDAC 2.6, IIS 5.0.
Validation rules before continuing with the installation are now clear. These are my LAUNCH CONDITIONS.

Answer: c) All ASP files - WebFolder under WWWRoot; DLLs, Exe's Files - Bin Folder under Application path; Config files - Config folder under Userprofile folder (Usually config is specific to users).

Folder locations are now known, these will be my FOLDER/FILE SYSTEM on target machine.

Answer: d) Add a registry entry of database connection string, save the organization details that user entered during installation in a configuration file. The post-installation action items are my CUSTOM ACTIONS on the target machine.

From the analysis that we did just now we know what are the action items. There are many installer software's available but I would like to go the MSI way using VS.NET. Advantages are:
MSI has become an international standard for setups.

VS.Net has sufficient features to create a professional setup. Cost of ownership is low.

Section II: VS.NET Setup Projects

II-1: Project Types

There are five types of setup and deployment projects in VS.NET, but three are of significant importance that are "SetUp Project", "Web Setup Project" and "Merge Module Project".

Display 1: Project Type dialog.

• Setup Project
  
  Generic type of project that could be used for all type of applications including web based application.
  
  
• Web SetUp Project
  
  Name suggests the type; this project type helps in creating virtual directories for web based applications during installation. 
  
  
• Merge Module Project
  
  When you want to install some additional third party software like MSDE along with your application then you can use this type of project. Use a *.msm extension based merge module installation of MSDE along with your own and create a setup.
  

II-2 Get Started

1) Select a SetUp Project type as shown in Display 1.

2) The default File System editor will appear in the window as shown in Display 2.



Display 2: Default File System Editor

3) One can add special folders here into which they intend to add files. Just right click on the editor to view the special folder types available. These are the folders into which you can drag and drop an entire folder structure with files.

4) Click on Registry editor and navigate to that editor (Display 3). One can configure registry settings here like "Manufacturer's name", "Version No", etc.

Display 3: Using registry editor

5) There is also Launch Conditions editor available. This is of greatest use since one can pre-validate for certain rules even before installation.

Validations can include file search, registry search, Component search or a particular deployment condition like as we mentioned earlier in section 1-2-b). Consider Display 4 where I added a Launch Condition and set the property condition as "PhysicalMemory>10000" i.e. 10GB and gave a custom error message "Physical Memory is less than 10GB." After the build when I tried to install it gave me error message as shown in Display 5 and cancelled the installation process, obviously my system had less than 5GB HD space and condition evaluated to false.

Note: For List of properties available go to MSDN help and search on Property Reference. There is a launch condition "MsiNetAssemblySupport" by default. This can be removed if computer on which your application is being installed does not support CLR.

Display 4: How to add condition to Launch condition.

Display 5: Launch validation!

6) File types editor is used to associate a default command action, File description , icon and extension for your custom files. There are many occasions we create new file-types with extensions like ".rmt" or ".cpg" etc. With the arrival of Win2k3 the rules specify that all files should have a default open command and an icon association. Please refer to display 7 and 8.

Note: Command association for the file is a must, hence need to associate an exe file.

Display 7: Configure default icon and extension for the file type.

Display 8 : Open command associated with the Notepad exe.

7) User Interface editor is provided in VS.Net by default with certain additional dialogs as per the requirements (refer display 9). Add for e.g. Textboxes (A) option that provides you with 4 textbox with edit value, label and property (Display 10). This is the most important editor since this is the UI that interfaces between the user and your MSI setup. The values captured from here are used throughout the installer like in Custom actions.

Display 9: Default view of User interface editor.

Display 10: See the EditLabel, EditProperty and Editvalue attributes.

Here if we pass the Editvalue as "Orbit-e", change EditLabel as Companyname and EditProperty as "COMPANYNAME"; in my custom actions section when I read the property "COMPANYNAME" it gives me "Orbit-e". This is the editor where in one can ask user to enter Company details, some configuration information like connectionstring for database etc.

8) Custom actions editor is where one adds some custom built *.exe, *.bat, *.wsh and other script files. As an example I have added a new C# windows application project as in Display 11. The following code in display that has a "Messagebox.Show" for a command line argument received. This could very well be any other functionality instead of Messsagebox.Show.



Display 11: Entry point has arguments to receive.

Once this is done, click Custom actions editor->Install->Add Custom action. This gives a dialog as shown below in display 12. Select Application folder->Add Output->Primary Output->Ok->Ok.

Display 12:Select application folder.

Now we are ready to pass the arguments for this primary output file as shown in Display 13. Pass the string [COMPANYNAME] in the "Arguments" (Pass multiple argument with some delimiter that is not a keyed character in same manner). Check "InstallerClass" property to False. This should be true only if this is a .Net installer class that can be used to programmatically access the MSI setup instances and databases. We will not discuss this since this is out of scope from this context.

Display 13: Configure the Custom action properties

NOTE: Refer to MSDN on types of custom actions and when are they fired, since this is crucial for your cleanup process in your un/installation.

9) Installer setup is now complete. Build the project and try to install. At one point in the installation process the setup throws up a Messagebox (Display 14) with the Winform and will continue only after this form is closed, since all these form part of a single installer session. This value was the same that was entered in the User Interface editor.

Display 14: Messagebox display from the Custom exe.

Note: There is one property that helps a lot that is [TARGETDIR] that gives the path where the user selected your application to install.

Conclusion

Though I have not been able to discuss complete technical features of VS.NET to create MSI, the features discussed in this article with some individual reading are very much sufficient to create a professional MSI installer. Installers are helpful for your deployment process but are not the only thing that affects this process; proper versioning of your assembly/dll's is also of primary importance. Happy Programming!