No Touch deployment

• Download demo project - 13 Kb

The day in class when the term “No touch deployment” was mentioned I tried to locate the code demoed in all the .NET Beta seminars I attended. Unable to find the code, I found the document distributed in class. This document led me to the Assembly class – where I was able to create the demo project in Figure 1.

Figure 1

Form frmTemp;

Assembly SimpAsm = Assembly.LoadFrom("http://Duron/asms/ClassLibrary1.dll");

frmTemp = (Form)SimpAsm.CreateInstance("ClassLibrary1.frmLoadMe");

frmTemp.Show();

Then in class a week latter, all these issues where addressed. I had not tested the demo, but I was under the impression it would load the DLL from the cache or from some the Temporary Download folder if a connection to the server was lost. When I did test it by shutting off the web site from the IIS administration tool (inetmgr.exe), I got the following results. The demo did pull the DLL from cache after it had previously downloaded it and was still running when the site was shut down.

This was on of the issues brought up in class. If the user was off-line, the DLL should still be accessible. In other words, every necessary file should be installed under the assumption the user will always be disconnected to the Internet. If the user is connected, updates should be automatically downloaded. In the event when launching the application after updates have been received, these updates should still work off line. To do this the DLL needed to be accessible.

I agreed with the presentation in the class, the best way would be to download the DLL to the hard drive or current working directory, compare it with a previous version of the DLL and then load the new DLL.

I wanted to do something simple like that in Figure 2, but that didn’t work. Here, strTemp represents the URL to the DLL.

Figure 2

if(File.Exists(strTemp))
{
    MessageBox.Show("Found it!");
    //File.Copy(strTemp, "lib.dll", true);
}
else
    MessageBox.Show("Nope!");

In playing around, I stumbled across the WebRequest and WebResponse classes. I created the demo in Figure 3 adapted from the code found in MSDN Library. I figure it isn’t my code - I never use “my” in naming variables. Anyway, again strTemp equals the URL to the DLL.

Figure 3

WebRequest myRequest = WebRequest.Create(strTemp);

// Return the response. 
WebResponse myResponse = myRequest.GetResponse();

MessageBox.Show(myResponse.ContentType + " " + myResponse.ContentLength.ToString());

// Code to use the WebResponse goes here.

// Close the response to free resources.
myResponse.Close();

This was great, because it displayed the number of bytes read from DLL on the web site. So did it download it somewhere to get this? I searched the MSDN Library again and discovered WebRequest’s progenitors, if you will: HttpWebRequest and HttpWebResponse. The created response object had a GetResponseStream member function! Sweet, we know streams!

After reading from the stream and writing the DLL to the current directory, I wanted to compare this DLL to the original one. See the code in the solution.

The solution includes two projects, one a simple C# forms application and a simple class library project that includes its own form. Compile both and copy the ClassLibrary1.DLL to the directory on the server hosting the web server or a virtual directory of the web server. Also, before running the AsmLoadFromApp application make sure you point the web request to the right place. Note: I hard coded the server name in the request.

The last part of the project was to determine the differences in the two files. On a quick inspection of the File class, I found a GetCreationTime static method. A good old, high level C# class! (I guess that is "good new C# class".)

Upon through testing, unfortunately comparing time stamps didn’t work. Every time the file was downloaded, it had a different creation time. Due to lack of time and probably desire too, I resorted to just replacing the old file all the time. This caused a problem though. Well, it just forces the user to shut down the application if he wants updates next time he runs it. The problem is like the one where you use the FromFile static method on the Image class. It is my understanding that the instance of the application has already downloaded and created the file. The reference to that file has already been popped off the stack and Windows still thinks it is being used. We seemed to be forced to just use the old file.

I hope some of this information was useful. I’m bummed it doesn’t seem clear how to compare files. I guess once it is downloaded the first time, you can set some flag and skip over the now unnecessary downloading. Even though it is just pulling it from the cache now unless the request somehow determines a change had been made to the file on the server. Discovering this supposed changed event would be slick. But finding this event was one of the purposes for this dang project anyway! Sorry, now I’m just venting.