A neat technique that can be used here is, when replacing an existing DLL, rename the DLL installed on the server to a different filename based on the version number. As shown above, use Windows Explorer to get the version number of the existing DLL and rename the file as shown:

Now copy the freshly compiled DLL and register it as normal. If it appears that something is wrong, stop IIS to release the lock on the DLL (stopping Web servers is a topic covered in some detail in Chapter 12), un-register the new DLL, rename the old DLL back to WroxCommerce.dll and register it again. Finally, restart IIS. The system should be back to its original state.

Permissions

Furthermore,Internet Information Server (the Web server that we will be deploying to) is tightly integrated with the Windows NT security subsystem. This means that it's possible to use NT security to control access either to all, or to parts of, any Web site. For most publicly accessible sites, IIS uses a special user account on the domain. When a user accesses the site, the IIS process pretends to be, or more correctly, impersonates this user to determine the access rights to various system resources. This anonymous user is created on installation and typically takes the name IUSR_machinename, so on my computer my anonymous user is called IUSR_BEETLE.

When you try and create an ActiveX component, the permissions set on the actual DLL that contains the components are checked to ensure that the IIS anonymous user has access. If that user doesn't, the file cannot be opened, and you'll see an error like this:

Microsoft VBScript runtime error '800a01ad' 
ActiveX component can't create object 
/site.asp, line 75

The 800a01ad is the key thing to look for here, as this is the error code for a permissions failure. If you're debugging the object from within Visual Basic, you won't usually see this error. The reason for this is the DLL that handles ActiveX object debugging (VB6Debug.dll which can be found in the Visual Basic directory) has no specific permissions set on installation and so by default it is always accessible to all users.

However, if you copy the DLL over to another server, depending on how your security is set up and how you are logged on to the remote server, you may see this error. This will only happen if the new file is installed with permissions that do not include the IIS anonymous user.

To resolve the problem, you just have to:

1. Use Windows Explorer to locate the file.
2. Right-click on the file, select Properties, change to the Security tab, and select Permissions.
3. Click Add...
4. Find the IIS anonymous user in the list, select it, make sure Type of Access: is set to Full Control, and click OK.

Here's what the permissions look like for the WroxCommerce.dll file with my IIS anonymous user in place: