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 or may not be the same 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 webserver, 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) 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. Both sets* include the following files:

File Name	Function
SAXFile.dll	Non-visual file-transfer engine
SAAXFile.dll	Visual (ActiveX) control
SAArch.dll	Archive file creation/extraction component
SAFilMgr.dll (Windows NT/2000) or SAFmgPws.dll (Windows 95/98/Me)	File management component

* SAXFShEx.dll (shell extension) is not included in the SoftArtisans signed CAB file, but is registered on the server with the default installation.

Why are there two different sets of dlls?
There are several reasons for this:

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 they will always warn of an impending upload or download, regardless of any browser security settings.
4. The individual dlls that are not included in the CAB file do not warn of impending 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?
Because 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 uninstallation 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. Please see: Upgrading XFile on the Client

How does the browser determine when dlls should be downloaded?
The browser will first check the 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 attribute.

<OBJECT classid="CLSID:230C3D02-DA27-11D2-8612-00A0C93EEA3C"
    height="200"
    codebase="/SAXFileSamples/saxfile.cab"
    id="AXFFile"
    style="HEIGHT:200px; LEFT:0px; TOP:0px; WIDTH:400px"
    width="400" VIEWASTEXT>
<OBJECT>

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 XFile on the Client

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 webserver so that the same machine may be used as a client for testing the client-side experience. Instructions for unregistering these dlls can be found at: http://support.softartisans.com/docs/XFile/install_uninstall.htm (Note:Skip the last step of deleting 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 webserver, that XFile cannot be instantiated server-side using "Server.CreateObject" for special server-side usage scenarios(server to server file transfer, cascading uploads). However, server-side use is not a typical use of XFile, since XFile would be limited by WinInet to four concurrent connections.

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. Instructions for removing these files via Internet Explorer can be found at: http://support.softartisans.com/kbview.aspx?ID=714