Implementing a Custom ClickOnce Server File Repository

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies.
This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
To create client business applications using current Microsoft technologies, see patterns & practices' Prism.

When a ClickOnce application is launched, the ClickOnce runtime on the client computer issues a series of file requests to the deployment server to download the files that are required to install and run the application. The requested files include the deployment manifest, the application manifest, and each of the application files (which are typically stored on the server with a .deploy file name extension). ClickOnce first requests the deployment manifest and obtains the URL to the application manifest from that file. Then it requests the application manifest and obtains the relative paths of each application file from that manifest. It then requests each application file based on that relative path from the location of the application manifest on the server.

You can use HTTP or a UNC file path to deploy ClickOnce applications. However, you can only use a UNC file path on the intranet because the file transfer from the deployment server to the client computer is simply a file copy performed by the operating system. As a result, there is no real opportunity to intercept the file request on the server and modify or control the file transfer process. If you choose to deploy your application over HTTP, you have more options and opportunities to control the process. HTTP requests are serviced by your Web server, and you can intercept the incoming file requests and obtain or modify the files as necessary before streaming them back in the response message.

For simple scenarios, you publish the ClickOnce files to a local folder and then copy them to a virtual directory on the Web server, as described in the other ClickOnce publishing topics in the Smart Client Software Factory. However, for more advanced scenarios, you may not want to store the manifests and application files on the server in the usual way. You may want to store the files in a database, and then dynamically retrieve them from a remote location, or dynamically generate them. If you use HTTP deployment, you can do these things by intercepting the file requests on the Web server and then dynamically obtaining the file streams from whatever location is appropriate for your requirements.

To do this in ASP.NET, you can use either an HTTP module or handler. Because the files themselves represent the endpoint of a request, a handler is more appropriate.

For information about how to implement this approach, see How to: Implement a Custom ClickOnce Deployment Server File Repository.