Deploying Windows Applications using Visual Studio 2010

Introduction

In previous versions of Visual Studio, you would deploy your application using a Setup Wizard. Microsoft has changed the model slightly and is nudging the developer toward the click-once model. You can easily deploy your application by clicking once in Visual Studio 2010. Read on and we'll show you how.

Step 1. Publishing the Project from Solution Explorer.

Right-click on the project in Solution Explorer you want to deploy. You'll see an option to Publish your project. Choose this option to bring up the one-click wizard.

Solution Explorer

Step 2. Select Where to Publish Your Deployed App.

The wizard will come up and prompt you where you want to publish your software. You really have a myriad of choices and are not limited to your hard drive. You can publish to a file share server, to the internet via FTP, or even directly to a website. Microsoft automagically figures out all the dependencies that need to be published. In this example, we'll use the default

Deployed App

Step 3. Selecting How Users Will Install the Application.

The next step gives you the flexibility of specifying where the user will install the application.

 Install the Application

Because of the internet and other networking vehicles, you are no longer limited from installing physical media. If you choose From a Website though, it appears you are limited to IIS as shown in the screen below. As it states you must have at least IIS 6 installed on the machine that will be deploying the app, and you must be an admin on that machine.

Local server

If you do happen to have an IIS Website and are an admin, you can type it into the Specify the URL field. After clicking Next, the Wizard will then prompt you whether or not the application will only be served up online or if the application can also run directly from the user's machine (offline).

Publish wizard

You can still install off of a CD, which is the default choice. We'll leave this choice checked in our example so we can package the app up in a zip file and send it to the user.

Step 4. Where the application can check for updates.

One of the nice features of Click-Once is that it has a software updating mechanism so the user can update their software whenever a new revision is available. In our example, we will pick a website to publish from so we can examine the update mechanism.

Software updating mechanism

Step 5. We are Finished!

The final screen tells us where the deployment files will be published and how they will behave on the client machine.

Deployment files

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.

CD

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).

Publish a project

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.


Similar Articles