Updater Application Block – Version 2.0 in a limited user environment

Set Up:
    I was recently involved in implementing the Updater Application Block version 2.0. The environment we were trying to implement the block in has two types of users, administrators and limited users. We started out implementing the in-process sample as it seemed like the most widely used and easiest to implement. There are a number of samples and articles written on the various coding sites that show how to use the updater block, and most of them basically mimic (if not plagiarize) the in-proc sample provided when you download and install the application updater block from Microsoft.
 
The Problem:
    In the restricted environment that our users would be working under, we were not able to get the in-proc sample to work cleanly. The updater would complete but when activating the updated version, a few issues arose. The first, and most minor issue, was that the "Wait for Exit" activation process opened up a console window that sat open until after the application had been terminated before it could run the updated executable. That is simply an annoyance to end users and will confuse them. Second, because of some issue with multi-threading the updater component, when the application was terminated, the updater thread would remain open. Each time we tested the application, another updater thread would appear in the list of active processes. This is a concern for anyone implementing a production application. The last issue that arose was that the updater process would actually successfully complete the update. When you ran the application after the exception was thrown by the activation process, the updated version would be run.
 
The Problem Diagnosing the Problem:
    In testing the sample on my personal laptop under a fresh limited user, the sample ran fine, throwing no exceptions. This all indicated that it was a problem within the corporate domain. This left us with one of a few options. We tried to diagnose the issue and have it resolved in the restricted user’s environment. As we, also, are not administrators in this environment, it made diagnosing the problem a pain because you had to call an administrator in to sit with you, log in after doing test X, then try again… bad use of time. Additionally, the logs created by the UAB were not accessible to restricted users in our environment. Remote debugging was not an option as we are not allowed to install anything in the restricted environment (for this reason we were, as well, not able to attempt the Windows Service option of the UAB deployment scenarios). Instrumentation also proved fruitless as the exception details indicated that the exception was occurring in anything but the UAB code. To better provide our client with the ability to upgrade the code to .Net 2.0 later on, rewriting the UAB was out of the question. UAB upgrades to ClickOnce, but not if you meddle with its inner workings.
 
The Resolution:
    Instead of using the in-process sample, we used the simple app-start sample as a guide. This implementation of the UAB does not require the "Wait For Exit" activation process and thus did not cause a problem in our restricted environment. One of our original design requirements was to be able to use XCopy deployment of our application, so the "Copy File" activation process (in the server manifest) used by this UAB implementation worked just fine.
 
References:

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s