No-Touch Deployment FAQ

View PDF

Traditional methods of deploying applications for a large user groups require significant effort to ensure that all users have the correct version, and problems are resolved uniformly across the installation.

The Microsoft .NET Framework 1.x introduced No-Touch Deployment, a feature that lets you package Windows Forms applications for easy distribution. No-Touch Deployment of .NET Windows Forms applications offers enormous savings of money and time, and improves the end user experience.

Despite its simplified installation, a review of technical articles, ADO.NET user forum comments and questions posed by developers at DataDirect Technologies customer meetings; it is apparent that many developers have difficulty implementing No-Touch Deployment.

DataDirect Technologies assembled this FAQ to help you understand what No-Touch Deployment is and what it can and cannot do. It explains how you can use No-Touch Deployment to distribute a 100% managed code DataDirect Connect for .NET data providers with your Windows Forms application.

No-Touch Deployment FAQs

What Is No-Touch Deployment?

No-Touch Deployment is a feature of the Microsoft .NET Framework that lets you package Windows Forms applications so they can be easily distributed to application clients.
Like browser-based application deployment, No Touch Deployment lets clients download the assemblies they need from a remote Web server. The first time an assembly is referenced, it is downloaded to a cache on the client and executed. After that, when the client accesses the application, the application checks the server to find out whether any assemblies have been updated. Any new or updated assemblies are downloaded to the download cache on the client, refreshing the application without any interaction with the end user.

Are No-Touch Deployment Applications Safe?

The .NET Framework security system allows administrators to define what privileges an application will have. For example, with the default settings, code loaded from an intranet Web server would not be allowed to access the client computer's Registry or file system, or access other servers on the network. The application could communicate with the originating site using Web Services. Administrators might define security policy based on internal company strong names when setting up applications for No-Touch Deployment. (1)
Isolated storage can be defined so that Internet applications can read and write files and directories. The size of the area is restricted, but is adequate to store user preferences and medium-sized files. (8)
Alternatively, if the application does not need to read or write files, it can be downloaded into the download cache on the client.

How to Implement No-Touch Deployment?

Application deployment can be implemented by recompiling the application with the build output set to the appropriate directory on the production Web server (which must have the .NET Framework installed.) Users browse to the location of the application using Internet Explorer 5.5 or higher. The application is downloaded into the download cache on the client.
Currently, there are several options for implementing No-Touch Deployment:
  • URL-launched executables
  • Assembly.LOADFrom Method
  • .NET Application Updater Application Block

When is it Appropriate to Use URL-launched Executables?

With URL-launched Executables, a company can distribute a Windows Forms application to all of its users by copying the executable to a Web server and distributing a URL that points to a Web page. A user browses to the URL and clicks on the link on the Web page to execute the program.
Alternatively, users can create a shortcut on their desktops to the directory. The executable is downloaded to the download cache on the client and launched from that location. DLLs required by the executable can be referenced as normal in the code.
This approach is appropriate when users are always connected on the local network and your application consists only of .NET assemblies with no external files (such as help files.) (2)

When Should the Assembly.LoadFrom Method Be Used?

The Assembly.LoadFrom method from the System.Reflection class can be used to create a small application stub on the client that loads assemblies residing on the remote Web server. The .NET Framework checks for updates when the application is run and downloads updated assemblies to the download cache.
The application stub only needs to reference the required DLLs on the Web server. The advantage of having the executable installed on the client machine is that the user will have an icon by which to launch the application. (5)
As with the URL-launched executable, this approach is appropriate when users are all known, are always connected on the local network and your application consists only of .NET assemblies (with no external files such as help files.) (2)

When Should the .NET Application Updater Application Block be Used?

The .NET Application Updater Application Block is an application block that enables the development of applications capable of automatic updating. This component is dropped into the existing .NET application. Properties are set to define the location of update files on the Web server and instruct how often the application should check for updates.
Although there is considerable flexibility in the implementation, the Application Updater Application Block assumes the use of either a Windows service or a shim executable.
Notes:
  • Using a Windows service is useful when you need to update multiple client and non-client applications to known customers. (For example, a corporate computing environment.) This approach is not recommended for sending smart client applications over the Internet to unknown customers. The application would be delivered to the download cache and would not be able to tell that updates are available. In addition, security considerations may not let you push updates to the client. (9)

  • Using a shim executable gives you control over updating the application and is easier to implement. However, the application must be restarted to complete the process. (5)
Automatic updates present a potential security risk. To minimize the risk during updates, give your updated assembly a strong name and enable the Validate Assemblies feature. (4)

Can No-Touch Deployment Be Used If the Application Has Shared Assemblies?

No-Touch Deployment does not directly support installing shared assemblies in the Global Assembly Cache (GAC). (7)
The GAC stores assemblies that are specifically designed to be shared by several applications on the computer. If one of the assemblies is placed in an application into the GAC, the application cannot be installed using the XCOPY command to copy the installation directory. The assembly must be moved separately into the GAC.

How Are Assemblies Deployed into the GAC (Global Assembly Cache)?

Installers, such as Windows Installer 2.0, provide assembly reference checking and other features when installing assemblies into the Global Assembly Cache. (7)
In addition, when you use Windows Installer 2.0, MSI will automatically install or reinstall assemblies as needed when an end user launches an application. The GACUTIL.EXE tool has an option to check references; however, the tool does not update assemblies. Further, the GACUTIL.EXE tool might not be installed on end user machines. (13) Therefore, you should use the GACUTIL.EXE tool only during development, and should not use it for deploying applications.
Assemblies that are installed in the GAC must have a strong name. However, strongly named assemblies (such as DataDirect Connect for .NET Data Providers) do not have to be installed in the GAC.

Is the Download Cache Part of the Global Assembly Cache?

The Global Assembly Cache (GAC) and the download cache are both part of the assembly cache. The GAC contains assemblies that are explicitly installed to be shared by several applications on the computer. The assembly manager creates new directories for each assembly installed in the GAC, although all of the assemblies are displayed in a single scrollable list. (11)
The download cache is located in the assembly directory; it stores code downloaded from Internet or intranet sites, isolated to the application that caused the download so that code downloaded on behalf of one application or page does not impact other applications. Assemblies that are installed in the download cache are later scavenged automatically. (6)
Figure 1
The Global Assembly Cache Tool (GACUTIL.EXE) is used to view and manipulate both the download cache and the GAC. However, the GACUTIL.EXE tool should be used only during development, and should not be used for deploying applications. (7)

Is the Download Cache the Same as Isolated Storage?

No. The download cache stores code downloaded from Internet or intranet sites. The application that caused the download is isolated so that code downloaded on behalf of one application or page does not impact other applications.
Isolated storage consists of data compartments, that is, areas that contain file system directories into which restricted assemblies can read and write files and directories. (8) Access to isolated storage is always restricted to the user who created it. The first time that code first attempts to open a store, the common language runtime decides whether to grant IsolatedStorageFilePermission, based on how much the code is trusted. If the permission is granted, the allowed usage and storage quota values are determined by security policy and by the code's request for IsolatedStorageFilePermission.
For example, suppose a developer has specified minimum permissions for a Windows Forms application that was designed for No-Touch Deployment. When the application is deployed from a remote Web server, the code is downloaded into the download cache. The common language runtime grants the appropriate IsolatedStorageFilePermission, based on security policy. A data compartment created for the application contains a directory on the file system that holds the user preferences and other data.

Can No-Touch Deployment Applications Write to the User's Disk?

The answer depends on the security defined for the application. In many situations, you might choose to use isolated storage, a secure cache in which the application can write to the disk, but cannot write to system files.

Can No-Touch Deployment Applications be Launched with Command-Line Arguments?

Yes. For more information, refer to "Launching No-Touch Applications with Command Line Arguments" by Chris Sells. (12)
This article in the MSDN Library provides custom code that you can use to create No-Touch Deployment Windows Forms applications, and includes recommendations on how to handle security.

Can No-Touch Deployment Be Used When Distributing a Windows Forms Application with a .NET Data Provider?

Yes, but only 100% managed code solutions, like the DataDirect Connect for .NET data providers, can use this deployment method effectively. Following deployment, the administrator will need to set the security policy on all of clients. Future updates and changes to the application will be delivered to the client by the Web server.
Suppose you want to bundle your Windows Forms application with a DataDirect Connect for .NET 2.2 data provider. To deploy the application on a Web server so that it can be executed through a Web browser on clients, you must embed the DataDirect Connect for .NET license file into the application. To do this from Visual Studio .NET:
1. Right-click the application project in the Solution Explorer and select Add Existing Item.
2. Browse to the DDTek.LIC file and click Open to add it to the project.
3. Right-click DDTEK.LIC and select Properties.
4. In the Build Action drop-down list, select Embedded Resource.
Figure 2
5. Build the application.
6. Deploy the application to the Web server. Refer to the Microsoft documentation for detailed instructions on using No-Touch Deployment. (5, 12)
Then, on the client, use the .NET Framework Wizard to define the security settings for the application and data provider. To do this:
1. Launch the .NET Framework Wizard (located under Control Panel/Administrative Tools).
Figure 3
2. Click Trust an Assembly.
3. On the first screen, accept the default value, make changes to this computer. Click Next.
4. Type in the URL of the application. Click Next.
5. Select This one assembly. Click Next.
6. Move the slider to "Full Trust". Click Next.
Figure 4
7. The changes you made are displayed on the Trust an Assembly screen. Check the values for accuracy and click Finish.
8. Repeat steps 2 through 7 on the DataDirect Connect for .NET provider DLL.
If the Trust an Assembly wizard method fails for some reason, check your security situation to see whether you can give Full Trust to the local intranet. If so, you can use the .NET Framework Adjust .NET Security Wizard to reset the security level.

Does the Version of the .NET Framework Matter?

Although Microsoft attempts to maintain forward and backward compatibility between versions of the .NET Framework, applications built using one version might have compatibility issues running on a different version of the Framework. (9)
When the version of the .NET Framework used to develop a URL-launched application is the same as the version on the client machine, the application can be deployed easily. Users should have no problems in accessing URL-launched executables. However, if the application was developed with one version of the .NET Framework, and the client machine has a different version of the Framework installed, users might not be able to access the application. When you test your application, be sure to include these scenarios.
In our testing in the DataDirect Technologies labs, we found that problems can occur when the application bundled with the DataDirect Connect for .NET data provider is built with version 1.1 of the .NET Framework and the client machine uses version 1.0 of the Framework. A FileNotFound exception is thrown.

When to Avoid Using No-Touch Deployment?

Sometimes you should use traditional installers for your applications. Use other installation methods for your Windows Forms applications when one of the following conditions applies:
  • Users need to use the application offline and might not have all options available to them. Because the application is stored in a cache on the user's machine, the application can run offline. Indeed, this is considered a benefit of No-Touch Deployment. However, the application runs only the features that have been downloaded and does not check the Web server for updates when running in offline mode.

  • Assemblies need to be deployed in the Global Assembly Cache (GAC).

  • The application cannot run within the default security policy, and deploying a different security policy is not practical.

  • Advanced installation operations are required, such as when a driver or data provider must be installed, or a COM object must be registered.

  • Your application or your .NET data provider makes calls to unmanaged code. Some .NET data providers require networking or client software, such as Oracle*NET or DB2 Connect. Using ODBC drivers or OLE DB providers under the bridges also requires calls to unmanaged code.
Thoughtful planning in the design stage of the application can reduce security and implementation issues. For additional information, refer to Microsoft's Deploying .NET Applications Lifecycle Guide. (5)

Can XCOPY Be Used Instead of No-Touch Deployment or a Windows Installer?

The self-describing nature of .NET assemblies allows you to deploy some .NET applications using XCOPY to copy files to a directory on the server. This makes XCOPY an appropriate choice in simple deployment scenarios. For example, XML Web Services and ASP.NET Web applications can be deployed with XCOPY. (14)
Typically, XCOPY is useful only in deployment scenarios that are simple and manually executed, for example, for applications that do not need to register the DLL or applications that do not require modifying the machine configuration file (Machine.config). Deploying an application using XCOPY does not copy the settings in the machine configuration file.
Be careful when using XCOPY deployment. The XCOPY command does not register or verify the location of assemblies. In addition, using XCOPY might overwrite files needed by other applications.
DataDirect providers can be used with XCOPY deployment.

What Are the Issues with Web-based Deployment?

Although Web-based deployment offers many advantages, the technique can have some drawbacks:
  • Users are not informed when updated files are being downloaded, and might notice performance lags over a network if the files are large.

  • Users might have to browse to a URL instead of clicking an icon to start the application.

  • The Web-based deployment mechanisms handle assemblies and .NET configuration files. Supporting files, such as help or XML data files, are not updated.

  • Assemblies deployed using Internet Explorer or the Assembly.LoadFrom method can only call back to the server from which they were downloaded. Security rights do not allow the assemblies to call Web services on another server.(2)

  • Internet Explorer is required. This type of Web-based deployment is not available to users of Mozilla Firefox.
Carefully assess these issues to decide whether moving to Web-based deployment is the right decision for your environment.

Where Can You Get Information about DataDirect Connect for .NET Data Providers?

DataDirect Technologies offers the following ADO.NET data providers, built with 100% managed code, that support the .NET Framework 1.x:
  • DataDirect Connect® for .NET 2.2 DB2 data provider

  • DataDirect Connect® for .NET 2.2 Oracle data provider

  • DataDirect Connect® for .NET 2.2 SQL Server data provider

  • DataDirect Connect® for .NET 2.2 Sybase data provider

  • DataDirect Connect® for .NET 5.5 data provider
For information about the DataDirect Connect for .NET data providers, see the "Previous Releases" section at:

Where Can I Obtain More Information About No-Touch Deployment?

The following sources were used to develop this FAQ .
For more information, search for "no-touch deployment" in the Help topics in the .NET Framework 1.x SDK and in the MSDN Library.

Download an evaluation version of DataDirect Connect for .NET

Buy | Download


Copyright © 1993 - 2008. Progress Software Corporation. All rights reserved. | N. America: 800 876 3101 | World: +44 (0) 1753 218 930