No-Touch Deployment in the .NET Framework
Summary: This article demonstrates an exciting new feature to simplify deploying and updating a Windows Form Smart Client using a Web Server. The Task Management sample application referenced in this paper is provided in Visual Basic .NET. (8 printed pages)
No-Touch Deployment Using a Web Server
Walking Through a Sample
Improving the Windows Form Responsiveness
No-Touch Deployment with Multi-Assembly Applications
No-Touch Deployment and XML Web services
Optional: How to set the Security Policies
Have you ever had to deploy a Visual Basic client server application? What about a Win32 application that relied on COM registration? Proper installation in a corporate desktop environment has been plagued with issues ranging from simple problems, like trying to get all of the users to upgrade, to far more complicated DLL versioning problems.
Desktop applications have a number of advantages over Web applications, specifically:
- Richer user interface (UI)
- Ability to run offline
- Efficient use of edge resources (client machines)
- Easy integration with local applications and APIs
In spite of these advantages, Web applications have gained tremendous popularity over the last few years due to the relative ease with which an application can be deployed and updated.
With the .NET Framework, Microsoft set out to bring all the deployment and maintenance advantages of the Web application to the desktop application. DLL versioning problems are eliminated: by default, applications built using the .NET Framework are completely isolated from one another, retrieving their DLLs from their own private application directories. DLLs can still be shared among multiple applications, but instead of using the system registry for this, the shared DLLs are stored in the .NET Framework global assembly cache, which can host multiple versions of a given DLL and keeps track of which version goes with which application. As for actually deploying the applications, the .NET Framework allows system administrators to deploy applications and updates to applications just as they would Web applications — via a remote Web server. This technology is called no-touch deployment and will be the focus of this white paper.
With no-touch deployment, Windows Forms applications — desktop applications built using the Windows Forms classes of the .NET Framework — can be downloaded, installed, and run directly on the users' machines without any alteration of the registry or shared system components.
How Does It Work?
The .NET Framework installation provides a mechanism to hook Internet Explorer 5.01 and above to listen for .NET assemblies that are being requested. During a request, the executable is downloaded to a location on disk called the assembly download cache. A process named IEExec then launches the application in an environment with constrained security settings.
Figure 1 No-Touch Deployment Scenario
We have a very straightforward Windows Forms application that allows the user to manage a list of tasks. These tasks could be used for bug tracking, IT ticket troubleshooting, or a to-do list similar to that found in Outlook XP or Visual Studio .NET.
To begin, open the application in Visual Studio .NET. The Task Management application is implemented in Visual Basic .NET using Windows Forms and an XML Web service named TaskMgmtWS which uses ADO.NET to communicate with an Access database to store the tasks.
The task management application uses the TaskMgmtWS Web service to update a DataGrid windows control. The application starts by instantiating an XML Web service object named ws. Then, a call is made to the web method GetTasks() to get an ADO.NET DataSet of tasks. The tasks DataSet is then assigned to the DataSource property on our DataGrid windows control.
' Call the Web service. Dim ws As localhost.Service1 = New localhost.Service1() Dim ds As DataSet = ws.GetTasks() ' Wire up the Data Grid control with the resulting DataSet. DataGrid1.DataSource = ds DataGrid1.DataMember = "Tasks"
When the application returns, the DataGrid is then updated and the application repaints. At this point, we have run into a common problem with a network-based application. During the initial load, the application is making a network call that may take a few seconds to complete.
To improve the overall responsiveness of the application, we can take advantage of background threads. The updated application starts by invoking a worker thread to instantiate an XML Web service object. Once the Web service has been instantiated, we use MethodInoker() to safely update the UI.
We start with the worker thread in the Form Load event:
' Use a background worker thread to make the Web service call to ' improve the overall responsive of the application during the ' initial form load. ThreadPool.QueueUserWorkItem(New WaitCallback(AddressOf GetTasksWebServiceBackground))
For more information on updating a Windows Form in background threads, please visit the Knowledge Base article Q318604, "Populate DataGrid on Background Thread with Data Binding by Using Visual Basic .NET" located at http://support.microsoft.com/default.aspx?scid=kb;en-us;Q318604.
While the Windows Form is running, we have a background thread that is working on the XML Web service call.
Private Sub GetTasksWebServiceBackground(ByVal data As Object) ' Call the Web service. Dim ws As localhost.Service1 = New localhost.Service1() m_ds = ws.GetTasks() ' Update the Windows Form data grid. Dim mi As New MethodInvoker(AddressOf UpdateDataGridForm) Dim ia As IAsyncResult = BeginInvoke(mi) Cursor = Cursors.Default End Sub
To demonstrate how to deploy the application to a Web server, we are going to deploy the Task Management application to the Tasks Web Service Web folder. We start by changing the build folder to the TaskMgmtWS Web Service IIS virtual directory. This can be done by opening the TaskManagement Property Pages dialog box and then setting the Output path to "..\TaskMgmtWS\".
With the build output path set to our Web server, we can now deploy the application by simply recompiling. Once the application is built, we can bring up Internet Explorer and browse to the application http://localhost/TaskMgmtWS/TaskManagement.exe. Notice that Internet Explorer with the .NET Framework installed will not ask you to save the application, but rather will attempt to run it. If you need the ability to download an application from within a web page, you can use the "file://" protocol handler.
The application is now pulled down via HTTP and installed into the assembly download cache. Before the application is run, the security policy will be checked to ensure the application has permission to conduct its operations.
Now that we have demonstrated how the application can be run from a Web server, let's make a change to the application and see how easy it is to update. Selecting the DataGrid, we can use the Auto Format property to quickly change the background styles.
The next step is to rebuild the application to update the .exe file on the Web server. The best part is that the application code is automatically updated when the user makes a request back to the Windows Form. The .NET Framework will automatically check the timestamp of the assembly to see if it needs to download again or if it can simply be run from the user's assembly download cache.
Code access security is the key to protecting the desktop from the Windows Forms applications that are being downloaded via no-touch deployment. This model works by matching applications to the permissions they should be assigned. At runtime, the common language runtime gathers evidence on an assembly. Evidence could take the form of what Internet Explorer zone the code came from —local disk, Intranet, Internet, trusted sites, untrusted sites — the URL the code originated from, any private key it is signed with, its hash value, an Authenticode publisher signature, and so on. Using this evidence, the common language runtime assigns the assembly to the appropriate Code Groups, or categories. Each Code Group has a permission set assigned to it, dictating which permissions the assembly should get, such as the ability to read from or write to the local disk, to access networked resources, to print, to access environment variables, and so on.
By default, the .NET Framework ships with Code Groups set up around the Internet Explorer zones. Code coming from the intranet zone, for example, gets a very constrained set of rights and may not perform File IO access.
To demonstrate the security checks in action, the Task Management executable contains a toolbar button named "Read Boot.ini" that attempts to access a file on C:\.
As a simple test, try clicking on the "Read Boot.ini" button to see what happens when the application requests a file in the root of C:\. A security exception is thrown and the application will not process the request.
The exception returns a File IO permission exception indicating that the application does not have access to that specific resource requested by TaskManagement.exe.
In this sample application, we have demonstrated how to load a single assembly. The .NET Framework also includes the ability to efficiently "trickle" multi-assembly applications to the client using the LoadFrom() method on an Assembly object.
The Assembly class has a LoadFrom method to initialize a reference to a particular assembly. The parameter for LoadFrom is either a URL or a file pathname. When a URL is specified, the .NET Framework first checks to see if the named assembly exists on the client by checking the assembly download cache. If the assembly is not in the assembly download cache, it is fetched from the Web server and a copy is placed in the download cache. Then the assembly object is ready for use in the code.
For instance, if the TaskManagement About Windows Form was implemented in a separate assembly named AboutForm.dll, we could use LoadFrom to pull down the assembly when the user made a request to see the About dialog box. By doing this, we would only be transferring the code that is needed for the application as the user interacted with the application.
An important security limitation is that when an application is being distributed via the Web server, its domain must match any of the Web services that it relies on. For example if we launch TaskManagement.exe from http://myserver/TaskManagement.exe, it is only allowed to consume XML Web services on http://myserver. The application would not be allowed to call a Web service from another server for security reasons.
Administrators on a machine can change security permissions to grant more permission to an existing code group or to create new code groups from scratch.
Before proceeding, it is important to understand that changing security settings is dangerous and should never be turned off. In all cases, it is highly recommended to only change the security settings to make the application run.
To do this, if you are an administrator on your machine, you can run the CasPol command line tool (located at %SystemRoot%\Microsoft.NET\Framework\v1.0.3705\CasPol.exe) to grant applications launched from localhost full access to the local disk:
caspol -machine -addgroup All_Code -url http://localhost/* FullTrust -n TaskManagement
Now the application will be able to return the contents of Boot.ini because it has permission to perform File IO.
In addition to the CasPol command line tool, a graphical configuration tool, called the .NET Framework Configuration Tool, is provided via a Microsoft Management Console (MMC) snap-in. After opening the snap-in, navigate to TaskManagement by opening My Computer, and clicking Runtime Security Policy, then Machine,then Code Groups, then All_Code. TaskManagement enables you to see the newly created code group. Try setting up a new code group to see how much flexibility and granularity is afforded by code access security.
Be sure to remove the code group created above after exploring the various options. This can be done by running the following command:
caspol -remgroup TaskManagement
You can also delete the new code group from the MMC tool by right-clicking on TaskManagement and selecting deleteThe tool allows you to easily generate an MSI file out of your code groups, which can then be rolled out across an enterprise using System Management Server or Group Policy, if desired.
- Any operating system that supports the .NET Framework
- .NET Framework with SP1
- Internet Explorer 5.0.1 and above
- Access to an IIS Web server for application deployment
No-touch deployment provides an excellent vehicle for distributing Window Forms applications. An application developer can harness the full processing power of the desktop while maintaining the deployment and maintenance benefits realized by Web applications.
For More Information
- Windows Forms Community Site
- Death of the Browser?
- Windows Forms Deployment
- Windows Forms Security
- For an excellent extension to No-Touch Deployment, visit the .NET Client Applications: .NET Application Updater Component