NetRun Design

The NetRun application is designed to be installed once on each client machine, and then used to launch other .NET applications (either Windows Forms or console applications). It accepts the URL of the application's EXE file as a command-line parameter, and it uses that URL to load both the EXE and the .remoteconfig file for the application.

Invoking the .NET runtime's support for no-touch deployment isn't difficult. In fact, it can be done in very few lines of code. All the complexity in NetRun comes because we're resolving the first three issues we discussed: security, serialization, and reading the configuration file.

To overcome the security issue, we'll grant FullTrust to the URL of the directory where the EXE resides. Once the application has terminated , we'll revoke FullTrust from that URL, so the system is reset to its starting state.

To overcome the serialization problem in dynamically loaded code, we'll set up an event handler to catch the event from the application domain that indicates there's a problem. In our handler, we'll fix the problem by providing a reference to the correct assembly, so that our objects can be deserialized.

It turns out that the biggest issue is the configuration file. As you know, all .NET code runs inside a .NET application domain, which provides the environment within which our code will runincluding knowledge of the configuration file. Inevitably, NetRun itself runs inside an application domainone that's set up to read from a configuration file named netrun.exe.config , which is located in the same directory as NetRun.exe . By the time our NetRun code is running, this is set in stone and cannot be changed.

In order to launch our application, we need to create and initialize a new application domain in which it will run. As we do this, we can specify the name of the configuration file that will be read for any code in the new application domain. This way, we can dictate that we want to read a file with a .remoteconfig extension.

Since we're creating a new application domain in order to specify the configuration file, we need to make sure that the security and serialization issues are resolved for that application domain , not for the one that's hosting NetRun itself. In other words, we don't need to enhance security or fix serialization for NetRun ; we need to fix it for the application we're loading dynamically.

This means that the basic flow of NetRun works as illustrated in Figure A-3.

Figure A-3: Process flow followed by the NetRun application

Notice how the main code in NetRun just configures a new application domain and loads a Launcher object into that domain to do the rest of the work. The Launcher class is our code, and it resides in NetRun.exe , but it's loaded into and executed in this new application domain.

The Launcher object then sets up the event handler for the serialization work-around , grants FullTrust to the URL where the EXE resides, and loads the EXE into memory. After that, it invokes the entry point (the special start method) of the application. When the application terminates, Launcher revokes FullTrust security from the URL, and then NetRun also terminates.