Unattended Sourceforge.net

This link contains useful information about various installer types:

Installshield
PackagefortheWeb
Wise InstallMaster
Inno Setup
Nullsoft Scriptable Install System
Ghost installer


http://unattended.sourceforge.net/installers.php

keywords: reference uninstall install command parameter

Mode of Use - the poison in the App-V mix.

Mode of Use - the poison in the App-V mix.


While the assocation can appear to work in testing - in the real world it does not work as the users require it to.

App1 physical (due to drivers. The app and drivers were not separated out) is launched outside the bubble

App2 has file association links to App1 and runs in a bubble.  If App1 is NOT running then the FTAs launch App1 in the bubble ok.  BUT if App1 is already running outside the bubble the FTA links fail because when they are attempted App1 outside the bubble can't see the file resources INSIDE the bubble.

e.g. ActivInspire=App1  and CuttingEdge=App2


Packaging (Preparing physical installs) and Virtualisation (preparing virtual applications) are generally regarded as very similar processes on the path to "application delivery" but in reality these two approaches are quite different.  To avoid wasteful reworking exercises it is important to select the best and most suitable approach is selected during the packaging phase(physical or virtual).  Application virtualisation is often seen as a desirable and as projects often try to set and predict percentages of virtualised applications that will be attained.  Often the targets are unrealistic because the limitations of virtualisation are not fully appreciated early in the project. 

The list of things that cannot be virtualised is relatively well known and typically includes
Drivers
Com+ components
Very Large >4Gb
Part of the operating system

Ideally, the physical or virtual decision should be made during the discovery phase or soon after the "packager" starts work.  There should also be the option to interogate expert users or application owners about the mode of use that is applied to the normal use of the software.

Types of software that should start to ring alarm bells are:
Software that interoperates with other applications.  See above.
Software that has ODBC connections that may need to be adjusted by advanced IT users.
Software that uses services that might sit quietly in the background.  Virtual services only become available when the app has been launched. (Websphere)

In addition there are items that have no technical restrictions to virtualisation but require changes to the way users operate the software. (Addins)  Is it reasonable to force (awkward?) changes to way users carry out their tasks just to accomodate the implemention of a new type of software delivery?  Often user communities will not accept changes to way things users work which shoot yet another hole in the numbers of applications that can be virtualised.

Virtualisation will usually be the default approach unless there is a reason it is not possible. In reality the number of apps that end up on the cannot/should not be virtualised because suprisingly and disappointingly large. The numbers begin to make it questionable what value virtualisation brings considering the additional operational complexity necessary to run two application delivery technologies.  One of the advantages of virtualising applications is that it can be relatively quick to run the sequencer and produce a virtual application.  However all that effort can easily go to waste once it arrives in front of a user and it does not work as they need it to.

Minitab 15 fails to virtualise in App-v 4.61

Configuration and Streaming launches in the sequencer appear to work fine however when attempted on a client the following error appears

Secure Loader Error
The Secure Loader user to protect this software has encountered a fatal error.  Please contact your software vendor.

Batch File Parameters

The below is copied from the link:

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/percent.mspx?mfr=true

See the link for more information on the modifiers.

You can use batch parameters anywhere within a batch file to extract information about your environment settings.

Cmd.exe provides the batch parameter expansion variables %0 through %9. When you use batch parameters in a batch file, %0 is replaced by the batch file name, and %1 through %9 are replaced by the corresponding arguments that you type at the command line. To access arguments beyond %9, you need to use the shift command. For more information about the shift command, see Shift The %* batch parameter is a wildcard reference to all the arguments, not including %0, that are passed to the batch file.

For example, to copy the contents from Folder1 to Folder2, where %1 is replaced by the value Folder1 and %2 is replaced by the value Folder2, type the following in a batch file called Mybatch.bat:

xcopy %1\*.* %2

To run the file, type:

mybatch.bat C:\folder1 D:\folder2

This has the same effect as typing the following in the batch file:

xcopy C:\folder1 \*.* D:\folder2

You can also use modifiers with batch parameters. Modifiers use current drive and directory information to expand the batch parameter as a partial or complete file or directory name. To use a modifier, type the percent (%) character followed by a tilde (~) character, and then type the appropriate modifier (that is, %~modifier).