No-Touch Deployment

No-touch deployment flows from reflection. As we saw in Chapter 3, reflection allows us to write code that examines and interacts with .NET assemblies, types, and objects: We can use reflection to load an assembly into memory from a URL (or the hard drive) dynamically; and once the assembly is in memory, reflection allows us to interact with it.

We can place .NET assemblies in a virtual directory on a web server, and .NET can download the files to each client machine automatically. On the server, this requires nothing specialjust a virtual directory (or some other directory that can be accessed via a URL). Into that directory, we can place all the EXE and DLL files required by our application. It doesn't have to be possible to browse the web directory, nor does it need any ASPX, ASMX, or other web- related files.

Once the files are accessible via a URL, the client workstation can use them. In fact, it's possible simply to create a web page with a link to the remote EXE. When the user clicks on that link, .NET will automatically download the EXE and run it on the client. If the EXE depends on any DLLs, .NET will automatically download them as required.

These automatically downloaded files are placed into a user-specific client-side cache. On subsequent attempts to run the application, the cached version is checked against the server version, and any updated files are downloaded automatically. If updates aren't required, the cached version is run.

Of course, such lofty claims are rarely as good as they soundno-touch deployment really does offer us the ability to deploy applications just by copying the code to a web directory, but there are some issues that we need to overcome to make it work the way we want it to. Specifically, we need to address the following:

• No-touch deployed code runs in an extremely secure environment that prevents the use of remoting, reflection, and serialization of objects.

• There's a bug in .NET that prevents serialization (using the binary formatter or the SOAP formatter) from working in no-touch deployed code, so even if you've overcome the security limitation so that the serialization could work, you'll have to deal with this bug.

• ASP.NET blocks the download of .config files, which typically prevent no- touch deployed code from reading an application configuration file.

• When an application is launched from a URL, the browser pops up for a second and then disappears before then the application loads; this is disconcerting to most users.

Fortunately, with a little effort, we can overcome all of these issues and enjoy the benefits of no-touch deployment to the full. In this appendix, we'll see how they're overcome by a single application NetRun.exe that needs to be installed once on each client workstation. Once installed, NetRun can be used to launch Windows Forms (or console) applications from a web server, via a URL. For instance, we could launch an application with the following command line:

  > netrun http://myserver/myroot/myapplication.exe  

NetRun uses the native, no-touch deployment functionality built into the .NET runtime; but it also addresses the preceding issues. Before we get into the development of NetRun , let's discuss those issues in a little more detail.

Security Considerations

Code deployed via no-touch deployment runs within a security context that's defined by the location the code was downloaded from. By default, this is controlled by the security zones that are defined by Internet Explorer, plus a couple of extras. In .NET, the only code that's fully trusted is code that's run from the local computer's hard drives all other code runs in a much more restrictive environment.

Tip 

Even code from a network shared drive or an intranet web server will run in the LocalIntranet_Zone , which prevents the use of remoting, reflection, object serialization, and a host of other common business application activities. Other zones (such as the Internet_Zone or the Trusted_Zone ) are even more restrictive.

Our CSLA .NET Framework relies on remoting, reflection, and object serialization to function, so these default security configurations are always too restrictive for deployment of CSLA-based applications.

Note 

In fact, remoting requires the highest level of permission: FullTrust . Any application that makes use of remoting must be fully trusted by the .NET security infrastructure.

Changing the default security for whole zones isn't recommended. Instead, we'll implement a solution where the security for a specific web directory, based on a URL, is temporarily granted FullTrust permissions while our application is running. When the application closes , the FullTrust permissions will be revoked .

Using NetRun , we'll get FullTrust for our business application without granting that permission to any other applications or code.

Object-Serialization Work-around

There's a bug in the .NET runtime that prevents the deserialization of objects in code that has been deployed via no-touch deployment, regardless of the security settings in effect. It only affects serialization using the BinaryFormatter or SoapFormatter , but since that's the type of serialization used by remoting and by our CSLA .NET Framework, it's a serious issue for us.

Tip 

If all we're doing is using the serialization techniques offered by the XML formatter and web services, we don't need to worry about this issue. Of course, these techniques don't make complete copies of our objects, so they're of little use when implementing a distributed, object-oriented application like those based on CSLA .NET.

The problem is that the deserialization process only scans locally loaded code to find the assembly that contains the class into which the data should be deserialized. Since our assemblies are loaded via no-touch deployment, the deserialization process fails to find them, and throws an exception.

Luckily, the .NET runtime raises an event prior to failing, and we can handle this event through our code to provide the .NET runtime with a reference to our assembly even though it was loaded via no-touch deployment. The code to do this isn't terribly complex, and by placing it in NetRun , we provide a work-around for our entire application, provided that NetRun is used to launch it.

Reading Application Configuration Settings

We're likely to use an ASP.NET web server as the source for our codethat is, the server where we'll copy the EXE file and any DLLs so that clients can download them. However, ASP.NET security prevents the download of any file ending in a .config extension to prevent people from downloading Web.config files and breaching website security. Unfortunately, our application configuration files also end in a .config extension, which means that ASP.NET will prevent our applications from downloading their configuration settings.

Tip 

This issue isn't a problem if the web server isn't IIS, or if our IIS server doesn't have ASP.NET installed. In those cases, the .config file can be downloaded like any other file.

It's possible to alter the security settings on an IIS web server to allow the downloading of .config files, but this isn't recommended. This could allow the download of machine.config or Web.config files for web applications on the server, and that's not our intentthe restrictions are there for good reasons. Instead, it's better to leave the server's security intact and change our client application to read some other type of file.

Note 

Altering the security settings on our web server to allow the download of .config files isn't recommended.

Fortunately, we can build functionality into NetRun to choose the name of the configuration file to be downloaded for our particular application. This means that we can request a configuration file with a different file extension from .config . In our case, we'll set things up so that our application uses a file ending in a .remoteconfig extension.

Preventing the Browser from Popping Up

The final issue is more cosmetic. The no-touch deployment functionality is built into the .NET runtime, and it works with Windows and Internet Explorer. This means that it's quite possible to launch a .NET application from the command prompt or from the Start Run dialog box just by providing a URL. An example is shown in Figure A-1.

Figure A-1: The Start Run dialog box to run an application from a URL

What happens here is that the browser launches, because we've specified an HTTP-based URL. The browser comes up, immediately realizes that it isn't needed, and closes. The result is an annoying (and potentially confusing) "flicker" of the browser on the screen before our application appears.

We could avoid this little glitch by having the user manually open the browser and then type our URL into the browser's Address field. Alternatively, we could provide the user with a web page that has a link to our application. Still, it seems rather counter-intuitive to force the user to open the browser just so that he can launch a Windows application.

Tip 

Additionally, launching applications this way means that we can't solve the first three problems we discussed. Without using some type of launcher application, there's no way to run code that resolves those issues before the application itself is launched.

The answer is to use a launcher programin our case, NetRun to run the application. The launcher program can directly invoke the .NET runtime to load the remote application code via no-touch deployment, thus avoiding bringing up the browser for no reason. We simply invoke NetRun on the command line instead, as shown in Figure A-2.

Figure A-2: Running an application using NetRun

This way, the browser doesn't pop up, and our application launches in an environment where all four of the issues are addressed, so everything works properly. A useful side effect is that we can put this command into a desktop shortcut or a shortcut in the user's Start menu, so that, to the user, our application is just another icon she clicks to run the programjust like she does for Excel, Word, or any other locally installed application.