Article Author: Brian Myers
Introduction
ClickOnce deployment is a new technology for deployment available in Visual Studio 2005 and .the NET Framework 2.0. This technology allows smart clients to be installed and run from a web site with one click instead of the wizard used by Windows Installer, as would typically have been done in previous versions of .NET. ClickOnce deployment also allows for updating of an application on the fly without another installation. The use of ClickOnce technology will greatly improve the deployment of Windows based applications. Previously Windows based applications needed to be installed with Windows Installer which required administrative permissions and made the applications difficult to update. ClickOnce deployment addresses all of these issues but it has its own set of disadvantages. This article will explain the uses of ClickOnce deployment and also compare ClickOnce to the traditional Windows Installer setup. Finally, it will show you how to develop, deploy, and update a windows based application deployed with ClickOnce technology.
System Requirements
To run the code for this sample you should have:
Installing and Compiling the Sample Code
The code for this project can be downloaded to a folder on your development computer. To deploy a ClickOnce application as described in this article you will need IIS installed and a virtual directory created to deploy the application from. The code provided with this article is only the base windows application described, you will need to make the modifications mentioned in the article to update the application and republish to see how the updated application works.
The Windows Based Application Deployment Issue
The company that I work for has many Windows based applications installed on client computers. All of these applications are in VB6 and often interface with manufacturing test equipment connected to the client. For the most part, these applications would be difficult to port to a web application. The deployment of these applications is difficult and time consuming as there are so many computers that need these applications installed.
A major problem the plagued the company was that applications for the desktop needed to be installed and maintained on each individual desktop. This used a lot of IT personnel resources to perform the installs and as a developer you need to worry about the configuration of each desktop and also about patches that come along, making sure they do not cause a problem with your applications. For the most part, those issues do not exist for web based applications. However, web based applications do have a limit to the user interface as it usually can not be as rich of an experience as a Windows based application.
My company would like to start moving the VB6 applications to VB.NET to take advantage of many of the new features and better development tools. However, there are several obstacles, one of those is that web applications could not work because of the interaction with the testing equipment connected to each computer and many of the applications run 24 hours a day and 7 days a week collecting data. Of course in the past with the VB6 applications there have been problems with getting new releases with updates out to the desktops and there have been problems with security patches and updates that have caused problems with existing applications.
I set out to help resolve this problem by investigating and creating standards and an infrastructure to support the new ClickOnce technology built into the .NET Framework 2.0 and Visual Studio 2005. The rest of this article gives a brief comparison of ClickOnce and the older Windows Installer technology, and then explains how to deploy a Smart Client application using ClickOnce technology.
Windows Application Deployment Options
There are two basic deployment strategies with Visual Studio 2005. The first is the traditional setup using the Windows Installer technology. The other is the new ClickOnce deployment. With Windows Installer deployment, the application is packaged into a setup.exe file that is distributed to users, so that each user individually runs the setup.exe file to install the application. With ClickOnce deployment you can publish the application to a central area and the user installs or runs the application from that location. With Windows Installer the setup.exe file must be run on the client; if it is runs on a public drive the application is installed on the server that is hosting that public drive. With ClickOnce deployment the application is automatically installed on the client computer.
ClickOnce
ClickOnce deployment can simplify the process of installation and updating an application. Applications deployed with ClickOnce can be self-updating – this will be shown later – which makes ClickOnce ideal for applications that require frequent changes. The self-updating feature of ClickOnce eliminates the need to revisit each desktop when a new update to the application needs to be installed. For a large operation, one that does not use a deployment tool like SMS (which allows you to deploy applications to the desktop from a central point), this can save plenty of time and money. If you deploy an application with ClickOnce technology you use the Publish Wizard that packages the application and the package can be published to a web site or network file share. The user installs and launches the application directly from that location in a single step instead of the installation wizard required by Windows Installer. Finally, ClickOnce deployment requires only Internet or Intranet Zone security permissions to install the application. The web site used for installation can be included in the trusted Intranet Zone within the browser on all clients and no additional security is required to install the application.
One disadvantage of ClickOnce is that the client must have network connectivity to take advantage of the update capabilities. So this would not be a good choice for example for a sales application installed on sales people’s laptops which are not always or very rarely connected to the network. One way to address this issue would be to deploy the ClickOnce deployment to an Internet web server which would allow the laptops to be updated anytime the computer is connected to the Internet. However, this would still require the laptop to be online. Another disadvantage of the ClickOnce deployment is the user may need to make a security decision – that could be difficult for less sophisticated users. A security decision may need to be made for applications that are to be deployed and require elevated trust, such as interaction with existing Office application such as Word. This can be mitigated by training, documentation, or finding ways to build the application without requiring the security decision. The final disadvantage of ClickOnce installation is it cannot install shared files, drivers, or install into the Global Assembly Cache (GAC).
Windows Installer
To deploy an application with Windows Installer you must add a Setup project to your solution which will create a setup.exe file to be distributed. The Windows Installer deployment allows the application to be installed for multiple users on the same computer as well as install drivers and finally install into the GAC. As noted above, ClickOnce does not allow these. Therefore if your application requires shared files, drivers for hardware for example, or you need to install a custom dll into the GAC you will need to use a Windows Installer deployment.
One disadvantage to Windows Installer is the setup file runs on the client and the user must follow a setup wizard. Another disadvantage is the developer must add code to the application to facilitate updates. Finally the Windows Installer requires administrator security permission to install your application.
To install a Windows based application using Windows Installer you need to add a new project to the solution within VS2005. This project can be added by clicking on the solution within the Solution Explorer and then choosing File , New Project . Under the Other Project Types node choose Setup and Deployment and then Setup Project as shown in Figure 1.
Figure 1. Creating a Setup Project
You can then change various options within the installer to suit your needs. I won’t go into any more depth on Windows Installer – see the Related Links section for more details on creating a Windows Installer project. I’ll point out though that once the options have been setup you build the installer by right clicking the installer project and choosing Build . A setup project and package is included in the code download within the WindowsInstaller folder as an example. The install package is within the folder called FirstDeployment within the WindowsInstaller folder. If you execute this package you will see that you must step thru an install wizard to setup the application.
Deploying a Windows Based Application with ClickOnce
The main components of the ClickOnce deployment architecture are two XML manifest files. The first is the application manifest ( FirstDeployment.exe.manifest ) which describes the application itself, including the assemblies, the dependencies and files that make up the application. This manifest also includes the required permissions and the location where updates will be available. Below is a portion of the application manifest. Take special note of the <assemblyidentity> , <PermissionSet> , and <dependentAssembly> tags.
<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 assembly.adaptive.xsd" manifestVersion="1.0" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns="urn:schemas-microsoft-com:asm.v2" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <asmv1:assemblyIdentity name="FirstDeployment.exe" version="1.0.0.0" publicKeyToken="56e48064947895ad" language="neutral" processorArchitecture="msil" type="win32" /> <application /> <entryPoint> <assemblyIdentity name="FirstDeployment" version="1.0.0.0" language="neutral" processorArchitecture="msil" /> <commandLine file="FirstDeployment.exe" parameters="" /> </entryPoint> <trustInfo> <security> <applicationRequestMinimum> <PermissionSet Unrestricted="true" ID="Custom" SameSite="site" /> <defaultAssemblyRequest permissionSetReference="Custom" /> </applicationRequestMinimum> </security> </trustInfo> <dependency> <dependentOS> <osVersionInfo> <os majorVersion="4" minorVersion="10" buildNumber="0" servicePackMajor="0" /> </osVersionInfo> </dependentOS> </dependency> <dependency> <dependentAssembly dependencyType="preRequisite" allowDelayedBinding="true"> <assemblyIdentity name="Microsoft.Windows.CommonLanguageRuntime" version="2.0.50215.312" /> </dependentAssembly> </dependency> <dependency>
The other manifest, the deployment manifest ( FirstDeployment.exe.manifest ) describes how the application is deployed,, including the location of the application manifest, and the version of the application that clients should run. Below is an example of the deployment manifest.
<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 assembly.adaptive.xsd" manifestVersion="1.0" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns="urn:schemas- microsoft-com:asm.v2" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xrml="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <assemblyIdentity name="FirstDeployment.application" version="1.0.0.0" publicKeyToken="0000000000000000" language="neutral" processorArchitecture="msil" xmlns="urn:schemas-microsoft-com:asm.v1" /> <description asmv2:publisher="FirstDeployment" asmv2:product="FirstDeployment" xmlns="urn:schemas-microsoft-com:asm.v1" /> <deployment install="true" mapFileExtensions="true"> <subscription> <update> <beforeApplicationStartup /> </update> </subscription> <deploymentProvider codebase="http://brianlaptop/FirstDeployment/FirstDeployment.application" /> </deployment> <dependency> <dependentAssembly dependencyType="install" allowDelayedBinding="true" codebase="FirstDeployment.exe.manifest" size="2167"> <assemblyIdentity name="FirstDeployment.exe" version="1.0.0.0" publicKeyToken="0000000000000000" language="neutral" processorArchitecture="msil" type="win32" /> <hash> <dsig:Transforms> <dsig:Transform Algorithm="urn:schemas-microsoft- com:HashTransforms.Identity" /> </dsig:Transforms> <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <dsig:DigestValue>nMR+WGyIu0J8i2PlR2Zim7QDgGw=</dsig:DigestValue> </hash> </dependentAssembly> </dependency>
</asmv1:assembly>
Notice the <update> and <deploymentProvider> tags in particular. The <update> tag tells when the update should be performed. The <deploymentProvider> tag tells where the update should be.
Both the application and deployment manifest can be created by using the Publish Wizard in Visual Studio 2005 or the manifest generate tool ( Mage.exe ) within the .NET Framework SDK.
The deployment manifest is copied to the deployment location. Again this can be a web server, network file share, or media. The application manifest and all application files are copied either to the same deployment location or another location that was specified in the deployment manifest. The Publish Wizard within Visual Studio 2005 copies the necessary files to the necessary locations automatically.
After the application is deployed the end users can download and install the application by clicking an icon representing the deployment manifest file on a web page or in a folder. The end user is usually only presented with a simple dialog box to confirm the installation (except when more permissions are required as discussed below). When the user confirms the installation the installation is performed and the application is launched automatically.
One important point to make about ClickOnce deployments is that they are isolated. The ClickOnce application is completely self-contained and each is installed to and run from a secure per-user, per-application cache. By doing this, the ClickOnce application will not break existing applications.
Deployment Choices
When deploying a Windows based application with ClickOnce deployment there are a few choices that need to be made.
The first choice is if the users are going to run the application locally or in an online-only mode. The local install of course installs the application on the computer and then it can be used offline (without automatic updates). When using the local install option the application can be installed from the web, a network share, or a CD. The online-only mode does not install the application on the local computer but the computer must have network and/or web connectivity all the time and the application will always be run from the deployment location (either network or web).
Installing from the web or network share
When installed from the web or network share (this is the default option) the application is deployed to a web server or a network file share. To install, the user clicks on a button or link on a web page or double-clicks an icon on the file share. The application is downloaded, installed, and started on the client computer. The installation adds an item to the Start menu and to the Add/Remove Programs within the Control Panel. Again, this option requires network connectivity during the installation and also for automatic updates.
Install from CD
When installing from a CD or DVD the media must be inserted – this can be setup to work with the autorun function or the installation can be double-clicked from the CD or DVD contents. As with the previous option the application is installed and started and the installation adds an item to the Start menu and to Add/Remove Programs within the Control Panel. This option does not require connectivity during installation, however, network connectivity is required to update the application. An update cannot be done from media, instead a new full install would be done.
Running the Application from the Web or Network Share
Instead of installing the application on the client, the application can be run from a web site, similarly to a web application. The user clicks on a web page or double-clicks an icon on the network share and the application is started. When the application is closed it is no longer available on the local computer. This option does not add to the Start menu or to the Add/Remove Programs within the Control Panel. Although the application is not installed permanently, it is downloaded and installed to the application cache on the local computer, just as a web application is downloaded to the web cache. Eventually the cache is cleared and the user believes the application was run from the web or file share. This approach is best used for applications that are not used frequently as there will be download and install time required for each use by the user. If the user is running the application multiple times in a day the application would need to be installed multiple times or kept running.
Update Choices
The second choice that needs to be made is how to check for updates. Periodically a ClickOnce application reads its deployment manifest file to see if updates are available. If there are updates available the new version is downloaded and run and only those files that have changed are downloaded. The choices for updating are: check for update on application startup, check for update after application startup or providing a user interface for updates.
Checking for Updates on Application Startup
When this option is selected the application will attempt to locate and read the deployment manifest file each time the user launches the application. Any updates that are available will be downloaded and launched. If there are no updates the existing version of the application will be launched. This option works best for high-bandwidth connections as there will be a delay in launching the application that has been updated which may be unacceptable with a low-bandwidth connection.
Checking for Updates after Application Startup
When this option is selected the application will attempt to locate and read the deployment manifest file in the background while the application is running. If any updates are available the user will be prompted to download and install the update the next time the application is loaded. This strategy works well for low-bandwidth users who may require lengthy downloads as the user is notified that an update is available and needed so the user understands the delay in opening the application.
Providing a User Interface for Updates
When this option is selected the application developer must provide a user interface that allows users to choose when or how often the application will check for updates. The ClickOnce deployment API provides a framework for programming your own update interface. You can see the System.Deployment.Application namespace for more information. This option works best if there are different strategies for different users.
Additional Options
In addition to the options just mentioned you can select how often the application will look for updates, and there are other options that you can set as well. First you can require updating. This option forces the application to be updated when the user runs the application next. This could be used to force all users to update their application after a major change or more specifically if the previous version and the new version are not compatible. The best way to guarantee an older version cannot be run is to use the Checking on application startup option. The other two options allow the user to interfere and not perform the update. You can also specify how often the application checks for updates. You can check for updates each time the application is run, once a week, or once a month. In this scenario if there is no network connectivity available the update check occurs the next time the application is run. Finally, you can block update checking altogether. You may have an application that will never need updating but you want to take advantage of the ease of deployment provided by ClickOnce. You can make a selection during the ClickOnce process that blocks update checking.
Security Choices
Applications that are deployed using ClickOnce are run with a limited set of permissions based on a security zone. If the deployment is run from the web or installed from the web, the security zone is the Internet Zone. If the deployment is run from a network share the security zone is the Intranet Zone. Finally if the deployment is installed from a CD, full trust is required. The permissions are based on the original version’s location and updates to the application inherit those permissions. Visual Studio 2005 does allow the developer to debug the application within the target security zone so as to verify the necessary security is present and not too much permission is granted.
If the deployed application requires special features such as interacting with Microsoft Office then elevated permissions may be required. If elevated permissions are required the user will be prompted during installation to accept or reject the necessary permissions. If the permissions are accepted the application will be installed, otherwise it will not. A ClickOnce deployment policy can be specified that defines a publisher as a trusted source. Any computer that has this policy applied will automatically grant elevated permissions without the user needing to be prompted.
You can control which deployments each user can access by not allowing anonymous access to ClickOnce applications deployed on a web server. Instead the access to deployments can be based on the user’s identity using Windows NT Authentication.
Publishing an Application with ClickOnce
Before publishing a ClickOnce application you need to determine where you want to place the application to be deployed. My example will use a virtual directory called FirstDeployment . To publish an application with ClickOnce open the project and right click the project name within the Solution Explorer and choose Publish as shown in Figure 2.
Figure 2. Choosing Publish from the Project Menu
When the Publish Wizard appears you can enter the path where you want the deployment to be published to. This can be a virtual directory on a web server, a file share, or a folder on the local computer. You can publish the deployment to a location such as a folder and then move it to another location for final deployment if you want. However, I have found it’s easier to point to the final deployment location if possible. You can click the Browse button to select the folder or you can type the path. Figure 3 below shows the deployment location form.
Figure 3. Choosing the publish location
This first example I will cover will install the application on the local computer instead of running the application online all the time. To do this, on the Will the application be available offline? screen of the Publish Wizard take the default Yes, this application is available online or offline as shown in Figure 4.
Figure 4. Deciding on the type of deployment
This option will install the application on the client as long as there is network connectivity allowing for updates. The next screen to appear will show you the summary information about the deployment. Click the Finish button to publish the application. First the application will be built and then published to the location you designated. Watch the bottom left corner of the Visual Studio IDE for the status of the deployment. When the status changes to Publish Succeeded then open the folder you selected for the deployment location. You will find a series of files there. This will include the application manifest, a setup.exe file, and a publish.htm file. The deployment manifest is located in the folder with the same name as the application with the revision on the end. For the sample application included this will be FirstDeployment_1_0_0_0 . The publish.htm file will be used later to perform the install.
You can make changes to the way the deployment is published by going to the Project Properties . To do this, right click the project within the Solution Explorer and choose Properties . The Project Properties window will appear. Click the Publish tab on the left. This will bring you to the Publish Properties as shown in Figure 5.
Figure 5. The publish properties of the project
Click the Updates button to open the Application Updates window. If you want to block automatic updates then uncheck the The application should check for updates check box. Then choose when the update should take place, either after the application starts or before the application starts. To require an update to occur you can click the Specify a minimum request version for this application check box and provide a revision level that is the minimum that all users must be running. This will require all computers not running that version to get the update when the application is run the next time. You can place the updates in another location and change the update location if you want, but this makes the process more complicated,, however you may have a need for that approach. For this sample, leave these options at the defaults.
Click the Options button to view other options that can be set. You can enter your company’s name as the Publisher name , you can include the Product name , and if you want a different htm file created you can change that setting within the Publish Options screen as shown below in Figure 6. Click OK to accept the changes.
Figure 6. Publish Options
Click the Publish Now button and the application will be published again. Now the revision level will be 1.0.0.1 . The revision level is automatically incremented unless you uncheck the Automatically increment the revision each publish on the main Publish Properties page. Also after the Publish Now button is clicked the Publish.htm page for that revision will appear. You can use this to test the deployment.
When the publish.htm file appears click the Install button. This will begin the installation of the deployment. Click Install when the security warning appears. This appears because the publisher is not known to the Windows system. You can avoid this message by signing the ClickOnce manifest with a known certificate. This topic is outside the scope of this article but further reading can be found in the Related Links section. The application will install and then appear. Notice the label says 1.0.0.0 , this is the build version of the application not the published version of the application. There is a difference, if you right click on the project within the Solution Explorer and choose Project Properties then click Assembly Information you will see the version of the application is 1.0.0.0 .
Now to show how the update infrastructure at work, close the running application. Go back to the Solution Explorer and open the Main.vb file. Add a text box to the form. Build the application by choosing Build FirstDeployment from the Build menu. Right click the project within the Solution Explorer again and open the Project Properties and click the Publish button. Click the Publish Now button which will publish version 1.0.0.1 . This time, do not click the Install button when the publish.htm page appears.
Go to the Start menu and choose Programs . Then choose FirstDeployment and execute the application. A window will appear stating there is an update available for the application and asks if you want to install the update as shown in Figure 7.
Figure 7. An update is available
When you click OK , the updated version is installed and run. You will notice that the text box that was added for deployment version 1.0.0.1 is on the form now. Also notice the build version is still 1.0.0.0 . Again this shows the deployment version and the product version are separate. This also shows that the update infrastructure is rather easy for both the developer and the user.
A Real-World Example
The example that was provided in the previous section was a simple one just to show the basics of ClickOnce deployment. This will work for simple applications that do not require additional files or additional resources outside of the .NET Framework. In this next section I will provide some information about more complex ClickOnce deployments which I learned while attempting to deploy a Smart Client application.
Most of the applications that I have worked on lately have been web based. However, a new project came to me that required interaction with an AS400 emulator and also printing labels. This really could not be a web based application and there are only a few users so I decided to make this a Smart Client application and hoped to use this to prove that the ClickOnce deployment strategy would work.
Within my application I have a file that needs to exist within the project’s folder when it’s installed. This file is actually a session file that will setup an AS400 session so the user does not need to do so. The first issue that I encountered was how to execute this application. My code uses this file to create a process which runs and displays the AS400 emulator. I discovered that a Smart Client application exists within the c:documents and settingsuserlocal settingsapps2.0 directory. As you can see the ClickOnce deployed application resides within the user’s area so there is no way to hard code the path to the file that I need to add to my application. Instead I used the Application.ExecutablePath to find the location of the .exe file which is the bin folder. Any file that is added to a project and published (I’ll show how to do this next) will reside in the bin folder. When you use Application.ExecutablePath you will also get the .exe file name at the end of the path. So I just used a replace statement to replace the .exe name with spaces which then gave me only the path. I used filepath = Replace(UCase(filepath), "Application.EXE", "") so filepath would get me the path to the bin folder and then I added the name of the file that I wanted to use.
After figuring out where the ClickOnce deployed application is placed on the client and figuring out how to interact with a file within that path I needed to figure out how to get my extra file into the bin folder so it could be executed. To do this I needed to add the file to the project as shown in Figure 8 ( AS400.ws is the file that I am adding):
Figure 8. Adding a file to the project
To have this file published into the bin folder so it can be used by the Smart Client application you need to change the Build Action property. To do this, right click the file and choose Properties . From the Properties change the Build Action property to Content and make sure the Copy to Output Directory property Copy Always as shown in Figure 9.
Figure 9. Changing Build Action to Content
After the Build Action is set to Content the file will appear in the Application Files list within the Publish Properties . To view this, open the Project Properties and click the Publish tab on the left. Then click the Application Files button and a window with the application files to include will appear as shown in Figure 10.
Figure 10. Application File list
Make sure the Publish Status is Include(Auto) , this will include the file when the ClickOnce deployment is published.
Another issue that I encountered was that I was originally planning to use the ReportViewer control in the application. This control allows you to include a report built with the SQL Server Business Intelligence tool. If you include controls such as this which is not part of the .NET Framework then you’ll need to include them as prerequisites. Prerequisites will be installed on the client the first time the ClickOnce deployment is installed. To setup a prerequisite open the project properties and click the Publish tab. Then click the Prerequisites button. The prerequisites list will appear and will show various packages that you have installed on your computer which may need to be installed as part of the ClickOnce package as shown in Figure 11.
Figure 11. Choosing prerequisites
The final issue that I encountered when attempting to deploy my first Smart Client application was that my application uses a COM dll to display a bar code. This dll file is necessary for the application to function. It is added as a reference within the project. However, when I installed the Smart Client the first time the application would fail when attempting to use the COM object. The issue is that ClickOnce deployment is meant to not harm or interfere with other applications on the client and therefore does not register dlls. Since the COM dll was not registered it could not be used. If you have a dll file like this you can use RegFree COM to allow your application to use the dll file without registering it. RegFree COM is a concept that some dll files can be used without being registered. This only works for dll’s that do not themselves need to use other applications. It is accomplished by isolating that dll from other files, but this is handled for you. When you add a COM dll file you may notice another reference added at the same time called OLE Automation. You must remove this reference. It will not harm to have it removed, but if you include the file then your deployment will not work. This OLE Automation file ( stdole.dll ) is required in the GAC which ClickOnce deployment can not be used for. But if you remove the reference then the deployment will work. To setup your COM dll file to use RegFree COM it must be isolated. To do this, open the project properties and click the References tab on the left. Find the COM reference you want to set as RegFree COM and double click it. This will bring up the properties window. Make sure the Copy Local property and the Isolated property are both set to True as shown in Figure 12.
Figure 12. Setting the Copy Local and Isolated properties
These are the major issues that I have encountered while deploying my first, more complicated Smart Client with ClickOnce deployment. Hopefully this will help you resolve issues faster as it took me several days to resolve these issues.
Conclusion
This article has briefly described the differences between a Windows Installer deployment and a ClickOnce deployment. This article also explained the basic architecture of a ClickOnce deployment as well as went thru step by step how to develop, deploy, and install an application with ClickOnce deployment. I have also provided some tips I have discovered when deploying a complicated real world application using the ClickOnce deployment method. With the new advantages of ClickOnce deployment more applications can be Windows based instead of web based and still provide for easy updating.
