<%
'Complus.asp - sample asp page to instantiate and test COMPLUS.Test
if Request("SUBMIT") = "" then
With Response
.write "<FORM ACTION=COMPLUS.ASP METHOD=POST>"
.write "<INPUT TYPE=TEXT NAME=MYNAME>Enter Your Name<BR>"
.write "<INPUT TYPE=SUBMIT NAME=SUBMIT VALUE=""SEND IT"">"
.write "</FORM>"
end with
else
DIM obj
set obj = Server.CreateObject("COMPLUS.TEST")
obj.CheckMe
set obj = Nothing
End if
%>
That's it! That's all it takes to gain access to the
ASP Intrinsics under COM+! Simply compile your component, run the COM+ Services
MMC, create a new COM+ Application, and import your compiled component "COMPLUS.TEST".
You should now be able to load the sample ASP page in your browser. The rest
is easy - you have access to the VB IDE for debugging and Intellisense to
create whatever type of custom business object you need. Er, that is until
you discover how to debug them in the IDE...
There is a minor "undocumented feature" of
VB COM+ debugging that you should be aware of:
When you debug a COM+ Component in Visual Basic 6.0 on
a Windows 2000-based computer, the following error message may appear in the
browser when the client is an Active Server Pages (ASP) page:
Server object, ASP 0178 (0x800A0005) The call to Server.CreateObject failed
while checking permissions. Access is denied to this object.
This behavior only occurs when you run the COM+ Component
from within the Visual Basic integrated development environment (IDE). The
error does not occur when you run the COM+ Component in a compiled state within
a COM+ application. The reason is that the authenticating user, usually the
IUSR_ account if you are using anonymous access, does not have
the appropriate permissions to access the DCOM Server (VB6.exe in this case).
Fortunately the solution is relatively simple:
1. Create an entry for VB ASP Debugging in DCOM: Start
Microsoft Notepad or another text editor and type the following case-sensitive
syntax:
REGEDIT4
[HKEY_CLASSES_ROOT\CLSID\{70F214BA-94E2-4bdf-8F30-32CB4A905E4D}] @="VB ASP
Debugging"
[HKEY_CLASSES_ROOT\CLSID\{70F214BA-94E2-4bdf-8F30-32CB4A905E4D}\LocalServer32]
@="vb6.exe"
[HKEY_CLASSES_ROOT\AppID\vb6.exe] "AppId"="{70F214BA-94E2-4bdf-8F30-32CB4A905E4D}"
Save the file as VBASPdebug.reg, and execute it by double
- clicking on it.
2. Add the Everyone account to the DCOM permissions for
Visual Basic ASP debugging.
Start DCOMCNFG. On the Start menu, click Run, and then type dcomcnfg in the
dialog box.
On the Distributed COM Configuration Properties page, click the Applications
tab, select VB ASP Debugging from the list, and then click Properties.
In the VB ASP Debugging Properties property sheet, click the Securities tab,
and then click to select the Use custom access permissions check box. Click
Edit.
In the Registry Value Permissions window, click Add, and then add the Everyone
account for Allow Access.
Click OK, and then click Apply to apply the changes and exit the Distributed
COM Configuration properties page.
Another workaround is to set the directory for the ASP
Page Application settings to HIGH (Isolated), and disable Anonymous Access.
Make sure Integrated Windows Authentication or Basic Authentication are checked.
If Integrated Windows authentication is used, then run the client browser
to access the ASP page under the same user account as the Visual Basic IDE
debug session. If Basic authentication is used, enter the username and password
for the same user account that the Visual Basic IDE debug session is running
under.
The details of these fixes can be found
in KB Q259725, "PRB: Error Occurs When You Debug a COM+ Component Under
the Visual Basic IDE with an ASP Client" in the Microsoft Knowledge Base.
Another common complaint is getting "Permission
Denied" or "Library Not Registered" errors when attempting
to instantiate your component in an ASP page. While some of the following
fixes are "undocumented", I suggest you try these:
1) The ASP ObjectContext and related utilities
can be found installed in the IIS Utilities Application under COM+. Try installing
your component that needs access to these in that same application right along
with them.
2) Make sure that the user context that
calls your component has permissions to actually launch it. What I do is go
to Local Users and Groups, and set the password to the IUSER_machinename account
to BLANK (no password). Then in COM+, right click on the Application (Package)
your component is in and set the authentication to the IUSR account. Now any
browser session should be able to run your component.
3) If all else fails, run DCOMcnfg and
make sure your chosen user has launch and access permissions to your component.
This short article and example should get you off to
a running start developing ASP components in Component Services.