Introduction

Pocket PCs that run Windows CE 3.0, a version of Windows, are 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 on 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 to the need for 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; the reason could well be no time allocation for the team to come up with automated installation plans. I can assure you that one can reduce around 30-40% of post-installation issues if you plan for a proper automated installer. We will look at 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 the 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 Hardware 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 the 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 the target machine.
Answer: d) Add a registry entry of database connection string, save the organization details that the 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 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. The 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 is "SetUp Project", "Web Setup Project" and "Merge Module Project".
SetupP1.gif
Display 1: Project Type dialog.
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.
SetupP2.jpg
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 the Registry Editor and navigate to that editor (Display 3). One can configure registry settings here like "Manufacturer's name", "Version No", etc.
SetupP3.jpg
Display 3: Using the 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 an error message as shown in Display 5 and canceled the installation process, obviously my system had less than 5GB HD space and condition evaluated to false.
Note: For a 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 the computer on which your application is being installed does not support CLR.
SetupP4.jpg
Display 4: How to add condition to Launch condition.
SetupP5.jpg
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 we need to associate an exe file.
SetupP6.jpg
Display 7: Configure the default icon and extension for the file type.
SetupP7.gif
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.
SetupP8.jpg
Display 9: Default view of User interface editor.
SetupP9.jpg
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 wherein 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 a display that has a "Messagebox.Show" for a command-line argument received. This could very well be any other functionality instead of Messsagebox.Show.
SetupP10.jpg
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.
SetupP11.jpg
Display 12: Select the 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 the 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.
SetupP12.gif
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) The installer setup is now complete. Build the project and try to install it. 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.
SetupP13.jpg
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!