Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Automatically Upgrade Your .NET Applications On-the-Fly : Page 2

Use the class library described in this article to add automatic upgrading to your .NET application.


advertisement
Setup Projects and Deployment
Visual Studio deployment projects (or third-party tools such as InstallShield, WISE, and others) give you the ability to create an install set that performs a variety of installation tasks. The install set can be deployed to a Web server or file server for easy access, but doing so doesn't help to keep the client application up to date. However, installing a rich client application this way does provide the benefits missing from Xcopy deployment:

  • You can create icons in the start menu or desktop during the install
  • The installed application appears in the Add/Remove programs control panel applet, and can take advantage of automatic repair and other Windows Installer features.
Web-based Deployment
You can also deliver applications to clients via the Web. There are two main ways to do that:

1. Launch Applications Using Internet Explorer: The .NET framework provides the ability to deploy your Windows Forms application via a Web browser, by entering the URL to the main application executable. For example:

http://yourcompany/apps/myapp/myapp.exe

Launching an application this way allows .NET to find any other assemblies it needs starting from the same location (application base) as the main application. You need to use the .NET Framework Configuration snap-in to configure your security policy so that it trusts code from the location you want to use.

Author's Note: When I tested this method, I ran into a few bugs, so keep in mind that some additional testing may be in order. For example, if your assembly name contains a space, as in "http://mydomain.com/my app.exe", Internet Explorer escapes the space characters automatically, and submits the escaped URL, which looks like http://mydomain.com/my%20app.exe. Unfortunately, the escaped space character causes a file not found exception. I also encountered difficulties using the System.IO.Path methods to load related files, because objects in the System.IO namespace do not appear to have been written for (and don't work well with) URLs (as opposed to UNC paths). This makes it difficult to write code that can be deployed directly or via the Web depending on circumstances.

2. Use Assembly.LoadFrom to create instances of objects. Another technique is to create an application stub that uses the Assembly.LoadFrom method to load assemblies from a Web server, for example:

With System.Reflection.Assembly.LoadFrom _ ("http://mycompany.com/myforms.dll") Ctype(Activator.CreateInstance( _ .GetType("Forms.Startup")), Windows.Forms.Form).Show End With

After your "entry" class is loaded, you don't have to use Assembly.LoadFrom to load subsequent classes—the .NET framework automatically loads instances of new classes from the location you specified for the original class.

Each time you run your application, the .NET framework checks for updates and automatically downloads updated assemblies to the application download cache. To use Assembly.LoadFrom in this manner, your users must always be connected—if they try to run your application while offline, they'll get an exception. While you can trap the error, I know of no way to force the framework to load the existing assemblies from the application download cache.

Unfortunately, Web-based deployment techniques also have some shortcomings:

  • Users are not informed that code is being downloaded. In a wide area network (Internet) scenario, that can mean a long wait if your files are large, with no automatic feedback to the end user.
  • Users must start Internet Explorer to launch your application rather than simply clicking a shortcut from the start menu.
  • The Web-based deployment mechanisms only handle assemblies and .NET configuration files. Other files associated with your application (such as help files or xml data files), are not upgraded automatically.
  • Assemblies loaded from a Web server via either the Assembly.LoadFrom method, or deployed using Internet Explorer run with limited security rights. According to the Deploying .NET applications: Lifecycle guide, "they can only call back to the server from which they were downloaded…a downloaded assembly cannot call a Web service on another computer."
  • In my tests, I found that the System.IO.Path and System.IO.File classes did not work as expected with an HTTP application base directory. In particular, executing the code such as that shown below returned False when BaseDirectory is an HTTP URL, even though the file exists in the specified location.


System.IO.File.Exists( _ System.IO.Path.Combine( _ AppDomain.CurrentDomain.BaseDirectory, _ "mydata.xml"))

Web-based deployment can work well, if:

  • Your users are all on the local network and are always connected;
  • Your application consists of .NET assemblies only—no help files, script files or any other external files that may need updating;
  • You are happy to have your users launch the application from Internet Explorer, or use a stub executable that uses Assembly.LoadFrom to launch your application.


Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date