Client-Side Installation


If you are testing your application by using your development machine as both the server and the client, the default installation of XFile may not be ideal for reproducing the client-side experience. This is because two sets of deliberately different dlls are provided with XFile, and the set of dlls that are registered on the server may not be the same set of dlls that are ultimately distributed and registered on the client.

Which dlls are registered on my server by default?

In a typical installation of XFile to a Web server, two sets of dlls are copied to the following directory: C:\Program Files\Software Artisans\SA-XFile. One set is wrapped in a cabinet file SAXFile.cab in XFileSE and SAXFileEE.cab in XFileEE) that is signed by SoftArtisans, and the other set is found as a collection of individual dlls in the directory. It is the second set of individual files that is registered on the server. The following table lists the files installed with each XFile editon:

XFileEE XFileSE Description
SAXFileEE.cab SAXFile.cab Cabinet file containing all XFile's dlls except SAXFShExEE.dll/SAXFShEx.dll.
SAXFileEE.dll SAXFile.dll Non-visual file-transfer engine
WebClient.dll WebClient.dll
SAAXFileEE.dll SAAXFile.dll Visual upload and download controls
SAXFShExEE.dll SAXFShEx.dll Shell extension (not included in the SoftArtisans signed CAB file
SAArch.dll SAArch.dll Archive file creation/extraction component
SAFilMgr.dll SAFilMgr.dll File management component

Why are there two different sets of dlls?
  1. In order to use the XFile server-side/ASP code samples, the dlls must be registered on the server. This requires that there exist at least one set of dlls that exist outside of a CAB file.

  2. In order to use the XFile client side/HTML code samples, the dlls must be available in a downloadable CAB file, or distributed and installed by some other method, client-side. Since internet distribution is the most common scenario, a signed CAB file has been provided so that the client-side/HTML code samples can be run immediately.

  3. To discourage malicious use of the CAB file that is signed by SoftArtisans, those dlls have been altered so that XFile will always warn the user before and upload or download, regardless of any browser security settings.

  4. The individual dlls that are not included in the CAB file do not warn the user before uploads and downloads. This allows for completely hidden and silent file transfer. If an application is to be developed with these dlls and distributed via the internet, they will need to be placed in their own CAB file and signed accordingly.
How does this pose special problems when the client and server are the same machine?

Since the XFile installation package already registered dlls on the machine, the browser will not attempt to download a CAB file*. You will not be reproducing the behavior the remote client will be experiencing. This means that the remote client may be receiving different dlls. The difference could be in the version number of the dlls. Likewise, the difference could be between the warning and non-warning dlls, or in rare circumstances of incomplete removal of an evaluation version, the difference could be between expiring and non-expiring versions of XFile. Other problems that could be masked might include an incorrect path to the CAB file or incorrect permissions on the file or it's directory.

The exception to this can occur when the version number is specified. For more information, see Upgrading SoftArtisans XFile.

How does the browser determine when dlls should be downloaded?

The browser will first check the <object> tag's clsid attribute and try to match that value in the registry. If it cannot be found, then it will attempt to download the CAB file from the path provided in the codebase.

<OBJECT classid="CLSID:230C3D02-DA27-11D2-8612-00A0C93EEA3C" id="AXFFile" 
codebase="/SAXFileSamples/saxfile.cab>
<OBJECT classid="CLSID:230C3D02-DA27-11D2-8612-00A0C93EEA3C" 

If that clsid can be found in the registry, the associated dll will provide the code that loads into the Web page, instead of the cab file that is referenced in the codebase attribute. Any time the clsid can be found in the registry, the browser will not attempt to download the CAB. The exception to this case can be created when the version of XFile is specified. This is convenient for forcing an upgrade of internet distributed dlls. For more information on this, see Upgrading SoftArtisans XFile.

Solution

There are two ways to prevent confusion when the client and server are the same machine.

  1. If you are planning to distribute XFile to your users using SoftArtisans (or your own) signed CAB file, then manually unregister the XFile dlls from the Web server so that the same machine may be used as a client for testing the client-side experience. For instructions, see Removing SoftArtisans XFile (Note: Do not delete the dlls if you still need them to create your own signed version of the cab file.) This will force the browser to download dlls from the cabinet file specified in the codebase attribute of the <object> tag in the Web page that instantiates XFile.

    It is also important to understand that if the dlls are no longer registered on the Web server, XFile cannot be instantiated server-side using Server.CreateObject for special server-side usage scenarios (server-to-server file transfer, cascading uploads).

  2. Test client-side behavior from a remote client on which XFile was not installed to compare behavior.

With either solution, it is important to understand that once XFile has been downloaded to the browser, those dlls will be registered on the client-machine via Internet Explorer. For repeated testing of the download process on the same client, it will be necessary to remove XFile from the client each time. For instructions on removing these files from Internet Explorer see Removing SoftArtisans XFile.


Copyright © 2000-2003 SoftArtisans, Inc. All rights reserved.