Thursday, August 25, 2005

NoTouch Deployment in .Net (MSDN)

No-Touch Deployment in .NET
July 2002
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. (12 printed pages)
Overview
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 various issues. These range 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)

  • Responsiveness

  • Performance

  • 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 in 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 which 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 document.
No-Touch Deployment using a Web Server
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 will be downloaded to a location on disk called the assembly download cache. A process named IEExec will then launch the application in an environment with constrained security settings.
(image placeholder)
Figure 1. No-Touch Deployment Scenario
Let’s walk through a sample
We have a very straight forward Windows Forms application that let’s the user 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.
Let’s first start off by taking a quick look at 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.
(image placeholder)
Figure 2. Task Management Visual Studio .NET Solution
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. Figure 3 demonstrates the application running:
(image placeholder)
Figure 3. Task Management Windows Form
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.
Improving the Windows Form Responsiveness
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 entitled “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 accessing the project properties for the TaskManagement Window Form project and then setting the Output path to “..\TaskMgmtWS\” as shown Figure 4.
(image placeholder)
Figure 4.  Task Management Build Options
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 now bring 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.
(image placeholder)
Figure 5. Run TaskManagement from Internet Explorer
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.
(image placeholder)
Figure 6. TaskMangement Running From the Browser
So we have demonstrated how the application can be “run from a Web server”, let's now 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.
(image placeholder)
Figure 7. TaskManagement DataGrid Properties
The next step is to rebuild the application to update the exe 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. The updated application is illustrated in Figure 8:
(image placeholder)
Figure 8. Reload the application in Internet Explorer
Security
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 IE 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, etc.  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 (ability to read from or write to the local disk, ability to access networked resources, ability, to print, ability to access environment variables, and so on).
By default, the .NET Framework ships with Code Groups set up around the IE 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 request a file in the root of C:\. A security exception is thrown and the application will not process the request as shown in Figure 9:
(image placeholder)
Figure 9. .NET Security Exception
The exception returns a File IO permission exception indicating that application does not have access to that specific resource requested by TaskManagement.exe.
No-Touch Deployment with Multi-Assembly Applications
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, .NET 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 can use LoadFrom to pull down the assembly when the user makes a request to see the About dialog. By doing this, we are only transferring the code that is needed for the application as the user interacts with the application.
No-Touch Deployment and XML Web services
An important security limitation is that when an application is being distributed via the Web Server, its domain must match any of its 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.
Optional: How to set the Security Policies
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.
(image placeholder)
Figure 10. Boot.ini Contents
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 My Computer -> Runtime Security Policy -> Machine -> Code Groups -> All_Code -> TaskManagement 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.
(image placeholder)
Figure 11. .NET Framework Configuration MMC
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 delete as shown in Figure 12.
(image placeholder)
Figure 12. Remove TaskManagement Group
The 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.
Client requirements
  • 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
Conclusion
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

posted by BO @ 2:15 PM 

0 Comments:

Post a Comment

<< Home