This solution lab demonstrates how to perform an initial application deployment
using AppLife Update.
The AppLife Update solution is designed to provide a solution for maintaining deployed
.Net applications. The vast array of possible .Net application environments demands
a great deal of flexibility in any updating and maintenance solution. AppLife Update
meets that demand. Using this flexibility, AppLife Update can also provide a solution
for initial application deployment, offering a compelling alternative to the Windows
Installer and ClickOnce for some application scenarios.
The concept is to create a simple “installer” application that will discover and
apply an update using AppLife Update. During this initial update, the AppLife Update
engine performs the installation of the primary application.
The download for this solution lab includes a Hello World example application
and corresponding installer. This installer application uses the AppLife Update
Controller to find and apply the “installer” update.
The installer uses the CheckForUpdateAsync and DownloadUpdateAsync
update controller methods to find and download the “installer” update.
The physical location on the deployed client to install the primary application
is passed into the “installer” update as the ApplyUpdate method is called.
The update can install anywhere the current user has permissions to write to. The
Hello World example assumes only limited permissions, and installs into the current
users local AppData folder. The install utility could be extended to allow the end-user
the ability to pick the install location.
As the update is applied, the NoRestart and AutoClose options are
used so that the update does not attempt to restart the installer application when
the “installer” update is finished. In the example application, the AppLife Update
engine user interface is displayed during the install. You could choose to customize
the user interface using the IUpdateUI interface features, or choose to
not show the update window at all by using the NoUpdateWindow option.
The install utility includes a Start application after install option. This
value is also passed into the update. The update will conditionally launch the primary
application at the end of the update, based on this checkbox value.
The “install” update uses an Add & Replace files action to place the primary
application assemblies in the install directory. This directory location was passed
into the update and is accessed using the designated Shared Property.
The Create file shortcut action is used to place a shortcut on the users
desktop to launch the application. A shortcut could also be placed in the users
Start Menu directory as well.
The install utility also supports uninstalling the application using the same concept
as installing. If the install utility is launched with a /uninstall command line
switch, the utility will use a different update location and look for an “uninstall”
update that will remove the application from the user’s computer. The “install”
update places registry keys that will add an entry for the application in the Windows
installed applications list. The user can uninstall the application from the Windows
Control Panel.
For easy deployment, the example download provides a download aspx page. The page
identifies the highest available “install” update and provides a link to download
the installer utility.
Hello World example application
install page
.Net Framework Dependency
The application installer utility is a .Net application and is therefore dependent
on the .Net Framework. The application install page looks at the http headers from
the client and determines if the .Net Framework is installed or not. If the .Net
Framework is not present, the install links are disabled and a link to get the Microsoft
.Net Framework is displayed.
Why the Self Extracting zip Option?
When Internet Explorer downloads a .Net executable from the local Intranet zone
or the Trusted Sites zone, it will launch the executable in a security sandbox using
IEExec.exe, a Microsoft shell application intended to provide .Net Smart Client
deployment functionality often referred to as no touch deployment or href exe. Executables
originating from the Internet zone cannot use IEExec.exe. Ironically, we don’t want
IEExec.exe to launch the installer executable. This is because the AppLife Update
controller uses IPC Remoting and requires a higher trust level than IEExec.exe allows,
without a customized client code access security configuration. So we don’t want the
installer exe to be launched with IEExec.exe regardless of the originating zone.
The desired behavior is to download the file to the remote system and launch the
application as its own process. Unfortunately, preventing this in Internet Explorer
without asking the user to save the file locally using the right-click context menu
requires a work around. One method is to wrap the .Net executable in a native process,
and a self-extracting zip serves this purpose. Another method is to change the http
response type when the file is requested using server-side code. This method is employed in the example
aspx page. Other browsers do not exhibit this behavior.
The flexibility offered by AppLife Update provides a deployment alternative to Windows
Installer and ClickOnce. For some application scenarios, the transparency, flexibility,
and capability you get with a deployment strategy centered on AppLife Update can
be compelling. With AppLife Update, you gain the ability to perform any action necessary
during an install/update, as well as an API that allows you to easily design an
update process that matches your application looks and behaviors.
For answers to questions about this example, please contact Kinetic Jump tech support.
techsupport@kineticjump.com