Chapter 3: Implementing the Deployment of .NET Framework-Based Applications

By now you should have learned about the different mechanisms for deploying .NET-based applications. In this chapter we go into more detail, showing you how to deploy your applications, either using no-touch deployment, Windows Installer deployment, or deploying a simple collection of build objects.

No-Touch Deployment

As mentioned in Chapter 2, "Planning the Deployment of .NET Framework-based Applications", for Windows Forms-based applications, you may choose no-touch deployment as the most appropriate deployment mechanism.

The .NET Framework installation provides a mechanism to hook Internet Explorer 5.01 and later 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.

To deploy an application using no-touch deployment, you need to simply recompile the application with the build output set to be the production Web server. Once the application is built, when a user browses to the location of the application, Internet Explorer will attempt to run the application. The application is now pulled down using 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.

Note

The client attempts will only attempt to run the application if it has at the Framework installed and Internet Explorer v.5.01 or later installed. Otherwise it will provide you with the options of opening or saving the application.

If you are going to use this method to deploy your Windows Forms-based applications, you have to determine how your users will launch the application. One approach is to provide the user with a URL to the Internet location. In this case, your application and any assemblies that are required are downloaded and then run in a security sandbox — they are downloaded to the .NET Framework assembly cache download folder and executed from there with either Internet or intranet zone privileges (which are minimal). With this approach no install is necessary at all on the client computer, as all code is downloaded as needed. Your application will automatically update whenever changes occur on the Web server. If files have changed, the newer versions are downloaded as needed, just as with normal Web browsing.

Note

If a user launches the executable from a URL and then sets Internet Explorer to work offline, then the application is also offline — no checks will be made for updated application files on the Web server until Internet Explorer is set back to online. This can lead to problems if an assembly is required while the user is offline, but that assembly has not yet been downloaded because it was not accessed in a previous session.

An alternative to launching the application from a URL is to distribute an application stub to the users. This stub simply contains code that loads assemblies from a Web server using the Assembly.LoadFrom() method. In these circumstances, you can manage security for the downloaded assemblies to grant them more privileges than those usually allowable for URL-launched applications. While changes on the server will still result in the application being updated on the client, any changes to the stub will need to be redistributed to each client computer.

By default, an application stub will not load assemblies from the cache without first checking the versions on the Web server. Instead, it will fail with an exception. This means that you should ensure that you have a reliable connection to the Web server, or write code to provide an offline mode for the application.

The main disadvantage of the application stub approach is that there is still some code to distribute to the client. However, this will generally be much simpler than distributing a full application and often a simple file copy is appropriate.

Note

For more information on using no-touch deployment, see the links at the end of this chapter.

Security Considerations

Users do not require administrative permission over their computers in order to install Windows Forms-based applications by no-touch deployment. However, it is possible to control the security of the applications when they run, using code access security. 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 CLR 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.

If necessary, you can change security permissions on the client computer to grant more permission to an existing code group or create new code groups from scratch. This is done using the CasPol tool or an MMC snap-in called the .NET Framework Configuration Tool. Each of these tools requires administrative permissions over the client machine to be useful.

One area where you may have to alter security settings to support no-touch deployment is if you have configuration files that need to be deployed with your application. In these circumstances you need to enable anonymous access for the directory that contains the config file. In many cases anonymous access will already be enabled, but if it is not, you should validate that this does not infringe on your overall security policy.

Another important security consideration is that any assemblies downloaded to the client computer can only call back to the domain from where it was downloaded. So, for example, a downloaded assembly from servera.microsoft.com cannot call a Web service on serverb.internal.microsoft.com. This security precaution prevents, for example, people from distributing code that performs denial-of-service attacks on some other server.

For more information on code access security, see Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication (Microsoft Press, ISBN: 0-7356-1890-0) or on MSDN.