Ok, so you want to stop being a wannabe programmer punk and decided to move into real development by making a couple of COM/VB components that you could use in your ASP development. Congratulations, it's a scary move but rewards are great. The best reward: you can debug the components straight from your VB IDE - no more Response.Write insanity.

So now you've created your first component, you clicked Run (btw, calling the Run button 'Play' is a dead giveaway that you are fresh from the ASP refugee camp), and went to your URL. And this is where the troubles start.

Access is denied to this object.
The most common problem developers encounters is as follows: you press F5 on your VB component, crank up the URL and get this: The call to Server.CreateObject failed while checking permissions. Access is denied to this object.. If you compile your code into a DLL, and run it as a DLL, everything will work OK, but not in the IDE. Why? The problem usually is that the web application is running under IUSR_MACHINE user name, which has no permissions to access the DCOM Server (VB6.exe in this case). Microsoft actually has a solution for you (Q259725), but it is too complicated and dumb. I have a better solution: Open Internet Service Manager. Right-click on your virtual directory and select Properties. Then go to the Directory Security tab, click the first Edit button you see on the dialog box, then click the first Edit button again. Now click Browse and select a user account that has Administrator rights. OKay your way out of it and the problem should go away. Some people might grumble that you shouldn't run your web app with an Admin account, but this is your development PC, so who cares.

I can't recompile my DLL/code.
This behaviour also affects newbie COM junkies. It happens under following circumstances: You compile your code and test it out by going to your URL. Then you attempt to change and recompile your code but VB says Permission Denied. No amount of restarting your VB project will allow you to recompile your code. Why? Because when IIS executes your DLL, it never lets go of it. Never. So what can you do? The immediate solution is to restart IIS. Fear not, it's easy. Executing this batch file will properly restart IIS and all its child services. You might want to edit it and customize, if necessary.

The long term solution is not to compile your code into a DLL, unless you really need it. Simply run the code in IDE. When you do compile it, for deployment to a production server or some such, simply delete it afterwards.

I pressed F5, but IIS is still running the DLL instead of my code.
This is the same problem as #2. Once IIS has got your DLL, it never lets go. Starting your VB project will not change that. So simply restart IIS using a batch file provided in #2.

How do I know whether IIS is running the code in my DLL or the IDE?
Place a breakpoint in the path of the code. If it breaks, obviously it is running in the IDE.

The code works on my machine, but fails on the production server.
Many scenarios yield these results but let's take a look at the most common ones.

• Permission Denied. Most likely you are running under IUSR_MACHINE user, which probably has limited rights. You are probably trying to access some resource to which the user has no access, such as a folder or file. If you are doing anything with ADO, always give your user read/write control over your TEMP directory. ADO and many other components use it to store temporary files.
• Cannot Create Object. Register the DLL using regsvr32.exe utility. Make sure (very important) that the DLL is registered by a user with Admin status. If it wasn't, you are probably in a world of hurt. Track down that user and have him/her unregister the component. Then find a user with admin rights and register it. If this is not done, not only will you not be able to create the object, you won't be able to register appropriately it in the future. If it were already registered properly, but you are still getting the error, make sure ISR_MACHINE user has read access to the HKEY_CLASSES_ROT branch of the registry. With all the security scares, corporations often wipe all the permissions and give them on a need-to-have-it basis.
• Data Source Name Not Found or Default Driver not specified. ODBC DSNs must be created by Admins. If they were not, then delete them and recreate using an Admin account. In addition, your IUSR_MACHINE user must have read access to the HKEY_LOCAL_MACHINE/Software/ODBC branch. If you are using Crystal Reports 8.x, get their latest update, because the boxed installation creates a supreme registry mess.