Deploying Windows Applications using Visual Studio 2010

Once you click the finish button, the folder where your deployment files automatically pops up on your machine. It even gives you an autorun file so that if you install your application on CD, it will set up your application as soon as the CD is popped into the player.

You'll also notice that publishing your application also adds a file with a pfx extension to your project. This file is an Authenticode Certificate. It is also known as a self-cert and will work, but will not identify you as a publisher. You would need to go to Thawte or Verisign to get a more secure certification. However, a self-cert will work for our purposes. To understand click once signing better, check out this msdn article.

Understanding the Deployment Structure

Click once is not only set up to be a one-time installation solution. It also checks for updates, making your application on the client live so that the user gets the benefit of fixes and changes to the app through the click-once mechanism. With Click Once, you can choose an update strategy. This strategy will determine how ClickOnce checks for updates. If you had selected, in step 4, check for updates, the .application file in your publish directory would contain the following section.

<deployment install="true" mapFileExtensions="true">
  <subscription>
    <update>
      <beforeApplicationStartup />
    </update>
  </subscription>
  <deploymentProvider codebase="http://www.microgold.com/TestDeployment.application" />
</deployment>

This strategy tells the application to check for updates before the application starts. If one exists, it will download the application and then start. What are some of the other possible strategies?

You could have the application check for updates every 10 hours while it is already running. If an update is available, the user will be prompted for the update the next time he runs the application.

<subscription>
    <update>
        <expiration maximumAge="10" unit="hours" />
    </update>
</subscription>

What if you wanted to require the user to install an update after a certain version of the app? You could add the following to the deployment tag of the click once .application configuration file.

<deployment install="true" minimumRequiredVersion="5.1.0.0">
    <subscription>
        <update>
            <beforeApplicationStartup />
        </update>
    </subscription>
    <deploymentProvider codebase="http://www.microgold.com/TestDeployment.application" />
</deployment>

Note. Every time you Publish a project from Visual Studio, it automatically creates a new revision for you. For example, the folder with version 1.0.0.1 below is generated (the numbers in the folder name represent major, minor, build, and revision). The .application file will point to the latest revision folder (TestDeployment_1_0_0_1).

TestDeployment_1_0_0_1 will contain your latest assemblies. In fact, if we just renamed TestDeployment.exe.deploy to TestDeployment.exe, it will actually run the app. Even if we have dependent assemblies in the project, they get deployed to this folder with the .deploy extension. Also, notice that each revision has its own local application file associated with it. This allows you to specify different deployment strategies for different revisions.

The .manifest file contains attributes about the assembly you are deploying. It also contains important security information about what type of permissions the assembly has to run on the deployed platform. The manifest also contains the publishers' identity and strong name signature.

Conclusion

Once your application is published the user can run setup to install the app. The application will automatically check for updates according to the update strategy you set in the .application file. This powerful set of features in Visual Studio makes deploying your .NET application a snap and makes it easy to keep it up to date.