Using CreateObject in ASP page

I have just started at new company and am trying to create a development environment replicating the stuff currently on the production webserver.

I have an ASP page containing the code below which is supposed to run an ActiveX DLL (SMSListener.dll).

Initially when I typed in the <filename>.asp in web browser, it gave error about not having permissions. I then realised I have to register the DLL with REGSVr32.

Now the ASP page is not throwing an error, but it is entering the 'else' part of the if statement below, and dosn't seem to create the ActiveX object (SMSListener.dll).

Can you suggest an easy way to debug what the ASP page is doing?

thanks (and no hurry, as I've now given up for the minute & I'm off home for the day!)
kester


<% Response.Buffer = true

Set objMsg = Server.CreateObject("SMSListener.clsMessageHandler")

objMsg.update Request.QueryString("message")


if objMsg.Response <> "" then
response.write("<b>" & objMsg.Response & "</b>")
else
response.write("<b>Failure</b><br>" & objMsg.Response & "<br>" & err.description)
response.write(" Message = " & request("message"))
response.write(" QSMessage = " & Request.Querystring("message"))
end if

%>

Until someone gives you a better answer...

When we use ActiveX DLLs in ASP, we register them in COM+ (COM/MTS depending on your server I guess) as part of a package.

So instead of Server.CreateObject("myDLL.Class") it is Server.CreateObject("myPackage.myDLL").

Maybe there are different ways of doing this, or maybe ActiveX DLLs need to be set up in COM? This is where we get into the fuzzy stuff to me (usually because it is transparent to the ASP).

Change

Code:

---

if objMsg.Response <> "" then

---

to

Code:

---

if Cstr(objMsg.Response) <> "" then

---

I'm betting that will either make it work, or throw a type mismatch, as I don't think your problem is with Creating the Object, but with the data types - VBScript treats everything as a variant, even if it actually is not.

Josh:

regarding using the Cstr(): I dont think this is the problem, as I think this page works on the production web server.

I really need a way of debugging the code i.e. How do I find out whether the object has been created or not?!

I dont suppose there is any way of stepping through the ASP code as in VB debug mode to see what it does when?!

CyberThug:

Thanks for the answer. However I dont really understand what ou mean! I dont suppose you could explain in slightly more depth?

Thanks both anyway!
Kester

I don't really understand COM/COM+/DCOM/MTS, so I can't go into more detail.

As to Josh's suggestion, try it. I got to thinking though. If the code is falling into the else clause, then your object is being istantiated. If it wasn't, then you would be getting an error durning the if test to the affect of "property or method does not exist".

I understand you can step-through ASPs with VID (Visual InterDev), but I never use it. I learned to program C++ in EMACS (which is just a fancy text editor). Old habits die hard. I still use a text editor for as much as I can.

Travis is right - the object was created, as Server.CreateObject didn't throw an error, and you are succesfully calling the objects methods, as there are no errors there either.

I haven't ever bothered with it, but the Interdev debugging needs a special IIS component - which I believe is a sub-component of the Front Page Extensions.:(

The server side debugging is not worth the effort. It's nice to be able to step through the code like in VB with F8, but it's such a pain. You have to ave FP extensions installed and you have to turn it on in the IIS MMC snap in on the server. Then it actually allows MsgBox server side. Dangerous if the server is unattended, you could end up poping up a modal dialog that stops the server until OK is clicked.

If you just want to verify the object was created use:

Code:

---

IsObject(objMsg)

---

But if you're not getting an error, it is created. Now untrapped errors inside the object are another matter altogether...

I think you're both correct about the fact that it was instantiating the original object. However I couldn't tell where the ActiveX DLL was failing (as there was no debugging type msgboxes or log file - since it was code that was already working on another web server)

I then tried putting in some debug info and recompiling and registering the DLL with a new name. MISTAKE!! as it got major problems - it got complately confused as to which DLL it was using etc, etc!

I used REGCLEAN and manually deleted ALL references to the original DLL from the registry (eventually!), and now finally I have got it sorted - well almost.

I have resorted to calling the DLL direct from a standard VB exe - then I can step through the DLL code and hopefully get it to work (if I can fix the failing SQL Insert statement - phew!); then recompile and eventually it should work from the ASP page.

thanks for all your help
A good learning experience for me who is new to ASP!

sorry MONTE, I wrote the previous comment before I'd read your reply.

I agree with your very sensible comments, especially regarding using the the IsObject check in the ASP (I have used it before from VB but didn't think of it in this case!)

I think the solution is: always get the DLL working from a standard VB exe first!!

Well I hope this will finally sort me out anyway!

Ta,
Kest

If you have IIS/PWS installed on the same computer you're making the VB DLL with, you can run the dll in the vb ide and debug the dll's code (not the asp code) when ASP accesses it.

Quote:

---

run the dll in the vb ide and debug the dll's code (not the asp code) when ASP accesses it.

---

Yes, this is what I now want to do.

I've determined that the ASP IS instantiating the DLL object.

I've finally got the DLL working, by calling it from a VB form (it now successfully inserts data to my database).

How do I get the ASP page to fire up the DLL in the VB IDE, rather than using the precompiles object?

thanks
kester

In the VB IDE, just run the DLL (F5), don't forget to add your breakpoints first!

Then when the DLL is called from ASP, it will use the memory resident version (your VB instance) instead of the compiled version.

Still having BIG PROBLEMS!!!

My activeX dll is created quite happily from a seperate VB exe using the CreateObject("dllName.classname")

When I now fire up the ASP page. I get the following error message:

Server object error 'ASP 0178 : 80070005'

Server.CreateObject Access Error

/test2.asp, line 7

The call to Server.CreateObject failed while checking permissions. Access is denied to this object.


I've looked at the MS Knowledge base articles and they do talk about checking your file and folder permissions, but as far as I can tell, I've changed all the relevant permissions to Read and Scripts and it hasn't helped.

Please help - I am getting desperate!

thanks
kester

You also need to make sure the IUSR_MachineName user has access to create objects.. You have to have some Windows Administration knowledge to get this all working sometimes..

And also remember that NTFS permissions can be set on registry keys.

Quote:

---

You have to have some Windows Administration knowledge to get this all working sometimes..

---

What do you do when you dont have Windows Admin knowledge??!! :confused:

This PC is running Windows XP so maybe there are some differences?

I have gone into 'Sharing and Security' and given Web Sharing access to READ and RUN SCRIPTS for my ActiveX dll (called Test.dll) and the MSVBVM60.dll (vb6 runtime file) [and all the folders they are in!].

I have searched through the registry for my activeX dll (test.dll) and the MSVBVM60.dll and gone to PERMISSIONS and ADDED full READ/WRITE access for IUSR_computername and INTERACTIVE.

There must be something trivial that I am missing???

Any ideas? Any good web resources for Windows XP administration?

Thanks for all your ideas and time so far!
kester

Kester,

Found this in the MSDN Library:

- Looks like permissions are needed for the NTFS 'Everyone' group! -

Quote:

---

BUG: ASP Error 80070005 "Server.CreateObject Access" When You Create a Visual Basic Component

Q278013


--------------------------------------------------------------------------------
The information in this article applies to:

Microsoft Visual Basic Professional Edition for Windows, version 6.0
Microsoft Visual Basic Enterprise Edition for Windows, version 6.0
Microsoft Internet Information Server

--------------------------------------------------------------------------------


SYMPTOMS
When you instantiate a Visual Basic component from an Active Server Pages (ASP) page, you may receive the following error:

Server object error 'ASP 0178 : 80070005'
Server.CreateObject Access Error

The call to Server.CreateObject failed while checking permissions. Access is denied to this object.
With Visual Studio 6.0 Service Pack 5 (SP5), you may receive the following error message:
Error number: -2147024891

ASP 0178 Server.CreateObject Access Error
The call to Server.CreateObject failed while checking permissions.
This error may occur after you install a new Visual Basic component on your Web server using a Standard Setup Package that was created on a computer with Microsoft Visual Studio 6.0 SP4 or SP5.



CAUSE
The authenticated user for the Visual Basic (VB) run-time file (Msvbvm60.dll) does not have sufficient permissions. The authenticated user is the IUSR_computername account when you use anonymous access or the user that is authenticated with the Web page.



RESOLUTION
To resolve this problem, assign Windows NT File System (NTFS) Read and Execute file permissions to the Everyone group (or to the appropriate users) for VB run time (Msvbvm60.dll). VB run time is usually located in the Winnt\System32 folder.



STATUS
Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article.



MORE INFORMATION
When you use the Standard Setup Package to update VB run time on the Web server, the setup application replaces the existing VB run time with the updated version when you restart your computer. In addition, the setup application replaces the NTFS file permissions for the Everyone group with the user who installs the new application. Because a Visual Basic component depends on VB run time, when you try to create your component, the CreateObject method fails due to insufficient permissions to VB run time.

---

Thanks for taking the time to look and responding so quick, mate!

I also saw this bug report and previously tried setting the permissions for the EVERYONE group. (Does this mean searching the registry for MSVBVM60, then in PERMISSIONS just selecting the tickboxes named FULL CONTROL and READ for the EVERYONE group?

Maybe I'm doing something wrong here?
Does it make a difference that I'm running the webserver on the same PC that I developed on?

Thanks
Kester

I'd personally stay clear of the Registry, as this may effect other applications using the VB runtime.
I’d just assign the permissions on the Security tab to everyone under NTFS (R-Click the MSVBVM60.DLL in WinnNT\System32 folder).
That is what the MSDN article refers to I think.

Regards

well I'd certainly like to stay away from the registry!

However I'm guessing this is different as its Windows XP.

When I R-click on file and go to properties there is no security tab (just the normal checkboxes for READ or ARCHIVE etc).

So i go to the File menu; then System32 [folder name]; then Sharing and Security; then the Web Sharing tab [which allows you to share this folder on IIS with permissions for scripts etc]

Maybe this is not the NTFS permissions that Microsoft are referring to?

I will look in the Help (aaaarrrrgh - must be getting desperate!) for NTFS.

Ta

sorry my mistake!

Not a Windows XP thing - just my lack of knowledge/experience!

I have unchecked 'Use simple file sharing [Recommended].' from the View file Types, and now the get the Security Tab that you said I would!

I'd guess you are not running NTFS!

NTFS (New Technologies File System). This is the type of format your hard disk must be formatted to prior to installing NT, 2000 or XP if you want higher secuirity.

I'd bet you are using FAT32! - under 'My Computer' R-Click the C: Drive icon and select properties, it should tell you what 'File System' you are using.

If you are using FAT32, the security permissions bug report may be a red herring - helpfull, but it is a Micro$oft OS!

If all else fails, rebuild the PC with a NTFS file system (required formatting C:\!), then re install XP, IIS, Visual Studio, Service Packs et all!

Sorry mate!

Replied before I knew you found the security tab, so I hope you can fix it now!

Good luck!

OH nO!

I thought that would have fixed the problem, but no such luck.

I restarted PC but still no luck.

I removed & unregistered my activeX dll.
Then I start the DLL up in the VB environment with a break point and call it from the ASP page and I STILL get the permissions error.

So it cant be with the actual dll file/folder - it must be with the memory resident version of the dll OR with this bloody MSVBVM60.dll. But I have done everything the microsoft article said!!!!