| The source files of a setup can be placed
on, and read from, various locations |
 |
The main setup.exe file itself |
 |
Physical media, such as a CD or DVD disc |
 |
Network file server |
 |
FTP server |
 |
HTTP/HTTPS server |
|
|
| When a setup is running, it
will attempt to access the source locations only if necessary. For
instance, a download may only be triggered when an application feature
has been selected by the user, or if an application runtime is missing
on the target system. |
| |
|
| The main setup.exe file will
contain your essential application files and runtimes—so your software
installs without requiring all of your users to keep their Internet
connection open during the setup process. |
| |
|
| When a web-based component
is needed, your user’s connections are handled seamlessly. If a download
is interrupted, the setup engine can resume exactly where it left off.
Downloads also transparently detect proxy server information. |
| |
|
| Setups may share the same
source locations. For instance, if two applications require the .NET
Framework, they can both read the framework from a single source
location, preventing the need to replicate source files and downloads
for each setup. |
| |
|
| How Does It Work? |
| InstallAware setups store each
source location as a web media block. Web media blocks serve as the
underlying architecture for WebAware installation technology and make
all of the above possible. |
| |
| What is a web media block? |
| A web media block is any part of your setup
that installs files. For example, you could have two media blocks—one
that serves your main application, and |
| another that serves your
sample projects. You can splice your setup into as many web media blocks
as you like. |
| |
| How does a web media block work? |
| When setup determines that a particular
file inside a media block will be installed, it downloads that block
from the exact URL provided. Building on the above example, if the user
chose to install your application, but not its sample projects, only the
main application files would be downloaded. The samples would not be
downloaded. |
| |
|
| How are web media blocks useful? |
| They help save bandwidth for your servers
and for your users. Users download only the features or dependencies
needed. |
| |
|
| Isn't this just
another web deployment? |
| No. Unlike most web
deployment schemes, web media blocks are free of constraints. Each web
media lock is contained in a single file, which you can deploy from any
URL. You can also precisely define which files in your setup belong to
which media blocks. Moreover, with traditional web deployment, all you
put online is an empty setup bootstrapper, which re-connects to the
Internet even to download always needed, vital application parts. This
can be avoided with WebAware installation technology by using offline
web media blocks. |
| |
|
| Can web and
offline content be mixed? |
| Yes. Using web media
blocks, you may even designate parts of your setup as "offline". Offline
content will always be included in your main setup file, therefore each
user that downloads your main setup program will not have to download it
from the web. This is useful for managing the parts of your setup that
are always required. |
| |
|
| Can common
runtimes be installed in this way? |
| This is one of the best
ways to use web media blocks. If your application requires runtimes that
may already be present on the end users system, simply place them inside
a web media block. That way, your setups will download the required
runtimes only if they are not already present on the target system. |