Deployment: Is Click Once best approach?

1) Is the deployment contained within the Enterprise, or are there external users?

2) CASPOL provides enterprise-level security where you can specify the trust level for the Intranet zone.

Bob

1. Deployment is to external users only.

2. Caspol wont work or I have to write some kind of C wrapper for CASPOL that then launches the .Net application but that seems a bit difficult.

If you are dealing with external users only, I prefer the .msi approach with a bootstrap installation of the .NET framework.  I am still waiting for the time when I can find that magic to install the .NET framework without having to include it in an installation, since the install file size is so large.

Bob

I dont quite understand what you are saying Bob.
What is the MSI approach with a bootstrap?

I think that I need to clarify somehting that I missed in my question.
The problem with the bootstrap and then launching the EXE is that the EXE launches MSI:s also and the Installation Engine doesnt allow nesting MSI:s.
Unless I am launching the EXE at the wrong moment.

Right now I use Click Once, which gives a setup.exe which installs a .Net framework.
But Click Once does not give me an MSI-file, it does something different.

My problem with MSI files is that if I package it in a normal MSI, I cannot launch other MSI from inside the EXE. If I use Click Once I can do this and bypass security, but it feels slow. The third way I have tried is to write my own application that launches the EXE after installing the .Net framework, but that gives me a security exception.

I see three ways to handle those machines where .Net is not present is:
1. Write an MSI package that installs .Net, launches the EXE that launches other MSI:s. Unfortunately this is not allowed since nesting MSI:s is not allowed.

2. Write own code to install .Net framework and then launch EXE that launches other MSI:s. This gives a security exception.

3. Click Once with full trust. Installs .Net framework and seems to have no security exception. The drawback seems to be speed.

Now, is there an alternative that I have missed or have I done anything wrong?

What you are looking for are called dependancies. You have a dependancy of the .NET framework (and I am sure there are others).

This can be 100% automated by use of an enterprise level product like WISE package studio.

This is accomplished by the use of what are called Merge Modules.  Merge Modules inside an .MSI are re-installable bits of code (.dll's, the framework, etc) that are installed if they are found to be missing on a target. You add the merge-module for the .net framework to your installation and it's automated from there. Inside the installer that is created it checks to see if it's dependancies are there (merge modules/etc), if they are found not to exist, are backdated/etc, it installs them without user interaction. You can of course customize this to a VERY great degree, but the default behavior is to automate it all for you.

This will then generate a complete installation package (with the necessary framework components) that will install the framework (IF necessary), and then install your application.

There are other ways (within the package studio) to accomplish this, such as deployment dependancy checking, but it will amount to the same thing....Some merge modules that check for dependancies on the target machines and installing them if necessary.

In the package creation options you simply check the option to create a single compiled install (the .MSI) and then run it via the method of your choice (command line with switches via msiexec.exe, a vbscript, or many other ways).

For security concerns you can use the Package signing utility to provide a certificate for the package.

We have one of the most locked down environments of any company on the planet (HIPAA, SOX, and other regulations regarding user data for health insurance) and have over 56,000 employees spread over 15 states.  The method I describe above is how our applications are deployed. Granted we use SMS to deploy them over the network and not a CD but the principles are identical.

Just a little more information about your very specific needs :

You mention several variants of the installation :
"I am writing the installation of an application.
It consists of 4 parts which can have different versions,
part 1: ver 4.2 and part 2: ver 5.1 and part 3: 6.2 and so on.
Each part has its own MSI installation."

I would suggest that the best approach for this is using an enterprise tool like WISE/Installshield as you can accomodate this very easily in a single installer that is not much larger via objects called "Features".

Your above would correspond to :
Feature 1: ver 4.2
Feature 2 : ver 5.1
Feauter 3 : ver 6.2

Essentially a "feature" is nothing more than a set of components that are installed on a target based on criteria you set. These criteria can be anything from searching for files, to registry settings, to workstation detectable attributes : Processor speed, memory, HD space, Operating system and many many more.

Inside the package, the feature would correspond to the files/settings/registry/etc objects you specify.

Once the installer is called, it looks through it's list of criteria, finds the match and installs the features you have grouped. You can also provide a "default" install if no specific set of criteria are found.

Rather than maintaining separate .MSI's that have quite possibly a lot of similar components, you create one "root" .MSI that contains all of the same core files, then contains the files that make each version "unique" grouped under features.

There are arguments on both sides of the table for this :

PROS :
By having a single root installer you save duplication of files across multiple installs.
You have a single install to maintain.
You can create transforms based on this single install to adapt to other conditions (localization/etc).

CONS:
By having a single root installer the single install can be larger, although this will depend on how many core components you have and how many objects make a version "unique" and the size of those objects.

Yet another option :
Create a compiled executable installer front-end using an enterprise level utility like Installshield/WISE. This is basically an "install script" that works like any other compiled executable but can be made "smart" to do the checking as to which "version" of your install should be called. Once it determines this it can then call that specific separate .MSI which you bundle with the installer or maintain on a share with the installer.

By using the .MSI / Windows installer route you are having LocalSystem (or an installation account you specify in the script) use normal trusted windows components to perform the install.

I mention an installation account because some environments are very-secured and can prevent the LocalSystem account from reaching out to the network via named/anonymous pipes. This is solved by using a domain level installation account.

If you are deploying to people outside of your domain, or to other companies/etc, an option is to download the entire installer locally and run it from there via the method of their choice/mandate.

Shakti109:

I use InstallShield, but I dont use it very often, once or twice per year.
It is my understanding that all features share a common upgrade code. When I distribute an upgrade in which all features are set to level 7.0 and the user selects feature 1 to be installed are not the other features automatically uninstalled?

One of my backup options is to execute the .Net code in a DLL from installshield and set criteria for the installation of features but I am worried about coexistance with other versions and uninstalling.

I will make some experiments based on your answers.

Just as an aside, the name of the .NET framework merge module (called redistributables by insallshield) may or may not look like :  dotnetfxredist_x86_language.msm

You will find any of these under what installshield calls the redistributables view which you can filter based on "objects", "Merge Modules", "all" (as of version 11).

I dont have time to research this question any more.
I went with the Click Once solution, it works well for my scenario.

I distribute the points between Shakti109 and TheLearnedOne for taking time to answer my question.