.NET Framework Developer's Guide
Application Deployment Prerequisites

To ensure that your application will install and run successfully, you must first ensure that all components upon which your application is dependent are already installed on the destination computer. For example, most applications created by using Visual Studio have a dependency on the .NET Framework; the correct version of the common language runtime must be present on the destination computer before the application is installed.

Platform Detection for ClickOnce

Before installing an application on a client computer, ClickOnce will examine the client to ensure that it has certain requirements specified in the application manifest. These include:

  • The minimum required version of the common language runtime, which is specified as an assembly dependency in the application manifest.

  • The minimum required version of the Windows operating system required by the application, as specified in the application manifest using the <osVersionInfo> element. (See <dependency> Element (ClickOnce Application))

  • The minimum version of any and all assemblies that must be preinstalled in the global assembly cache (GAC), as specified by assembly dependency declarations in the assembly manifest.

ClickOnce can detect missing prerequisites, but cannot install them. If any of these platform dependencies are found to be missing, ClickOnce halts installation and presents an error dialog box to the user.

NoteNote:

There is no tool support for setting specific versions of the .NET Framework and the operating system within the manifest. To change the default values generated by tools such as Visual Studio and MageUI.exe, you need to edit the application manifest in a text editor, and then re-sign both the application and deployment manifests.

Bootstrapping for ClickOnce Applications

Missing prerequisites must be installed using separate redistributable packages. The deployment tools in Visual Studio let you install the .NET Framework and other redistributables as a part of your installation—a practice known as bootstrapping.

Visual Studio includes the following deployable packages:

  • .NET Framework version 2.0 

  • Microsoft Data Access Components (MDAC) 2.8

  • SQL Server 2005 Express Edition

  • Windows Installer 2.0

By default, bootstrapping is enabled for both Windows Installer deployment and deployment with ClickOnce. You can disable bootstrapping for a component, but you should only do so if you are sure that the correct version of the component is already installed on all target computers.

When you deploy a ClickOnce application by using Visual Studio, the development environment will prompt you if you want to include certain redistributables, such as the .NET Framework, as dependencies. If you select one or more of these options, Visual Studio will generate a Windows executable program named Setup.exe (the "bootstrapper") that is responsible for installing these dependencies before your application runs. This bootstrapper runs as a separate process that is independent of the ClickOnce run-time engine.

With ClickOnce deployment, the Publish.htm page generated by the ClickOnce Publish Wizard points either to a link that installs only the application or to a link that installs both the application and the bootstrapped components.

If you do not use Visual Studio, but compile your applications on the command line, you can create the ClickOnce bootstrapping application by using a Microsoft Build Engine (MSBuild) task. This is the same build task that Visual Studio uses to generate the bootstrapping application. For more information, see GenerateBootstrapper Task. For more information about how to use MSBuild to compile projects, see MSBuild Overview.

During installation, users on certain Windows operating systems may be prompted for administrative permissions to run the redistributables, even if they are already installed.

As an alternative to bootstrapping, you can pre-deploy components using an electronic software distribution system, such as Microsoft Systems Management Server (SMS).

Bootstrapping Application (Setup.exe) Command Line Arguments

The Setup.exe generated by Visual Studio and the MSBuild tasks supports the following small set of command-line arguments. Any arguments supplied to the bootstrapping application beyond these are forwarded to the application installer.

Term

Definition

-?

-h

-help

Displays a Help dialog box.

-url

-componentsurl

Shows the stored URL and -componentsurl for this set up.

-url=location

Sets the URL where Setup.exe will look for the ClickOnce application.

-componentsurl=location

Sets the URL where Setup.exe will look for the dependencies, such as the .NET Framework.

-homesite=true|false

When true, downloads the dependencies from the preferred location on the vendor's site. This overrides the -componentsurl setting. When false, downloads the dependencies from the URL specified by -componentsurl.

See Also

Concepts

Tags :


Community Content

Thomas Lee
Other undocumented command line switches
I've come accross an example of an undocumented switch "/dest" which can be used to specify the destination full path for the file that should be created with the url or componentsurl modifications.

it seems that currently several developers are looking for a solution for the issue that scripting these commands is difficult due to to a message box prompt that is given the first time any of these parameters are modified. What I'm curious about is whether there are any other undocumented switches that we can use to run the setup.exe command line in silent mode (eg. /q).
Tags : contentbug?

Thomas Lee
Issue with using the -url switch
The following information on the Microsoft Feedback site states that the issue regarding the unwanted prompting when running the command line switches on setup.exe had already been solved.

http://social.msdn.microsoft.com/forums/en-US/winformssetup/thread/c3c5063c-9f5a-4754-81f7-990d82f5855c/there%20is%20now%20way%20to%20get%20%E2%80%98setup.exe%20%E2%80%93url%20%E2%80%98%20%20to%20suppress%20messages

Unfortunately it seems that as evidence of the posts on this topic found around the web that the Program Manager himself is inaccurate when he states "We changed the behavior of the -url switch in setup.exe for Visual Studio 2008 so that it did not prompt".

Another problem is that after using the /url switch to change out the URL and manually confirming that the signature will be invalided for the assembly, using SignTool in order to re-sign the setup.exe bootstrapper seems to fail with the following error.

SignTool Error: ISignedCode::Sign returned error: 0x80070057
The parameter is incorrect.
SignTool Error: An error occurred while attempting to sign: setup.exe

Number of files successfully Signed: 0
Number of warnings: 0
Number of errors: 1


So as far as I can see that from a scripting perspective the /url and other such capabilities are pretty much useless and if they were not created for scripting purposes what purpose were they created for.

Page view tracker