I have CodeSite Express, bundled with Delphi XE Enterprise. Right now I'm developing an ISAPI application in XE (I trace and debug using attach to process in XE - works fine) and I'd like to get some CodeSite messages out of my ISAPI application.
In Advanced Techniques in the included CodeSite help, I found this:
"Logging From Services
Service applications run in a separate window station from that of the desktop. However, by default, the CodeSite Dispatcher runs in the desktop window station. As a result, the default message transport mechanism used to transfer CodeSite messages to the Dispatcher, the wm_CopyData window message, is blocked by Windows. Microsoft Windows does not allow window messages to cross window station boundaries..... Therefore, if we wish to send CodeSite messages from a service application to the Dispatcher, we need to connect to the Dispatcher using the TCP protocol instead of CopyData."
Question:
Am I corrent in assuming that the same rules are applicable to ISAPI applications? That I have to use TCP to get CodeSite messages out of ISAPI apps?
Given the fact that the ISAPI is loaded from IIS and IIS is running as a service, yes.
In the default configuration, yes. But there's more.
I'm not sure about newer versions, but in IIS 6, when you select isolation level high, your ISAPI dll is run from a dllhost.exe process over COM+. With the Components Services administration tool (formerly known as DCOM config) you can change the 'activation' configuration to use the currently logged on user, and the dllhost.exe instance will run in the active window station. (You can even start dllhost.exe as a host application to the Delphi debugger, with the /ProcessID:{} parameter and a guid of the COM+ entry)
What I've seen so far in IIS 7, is that w3wp.exe now loads and runs ISAPI dll's, but I'm not sure if something like the above applies. You may check if application pool settings have a similar activation setting.
Related
I am using Delphi 7 pro and debugging an older ISAPI app with IIS 7.5 (Windows 7).
Everything works fine except that if I place my cursor over a property to see the current value, sometimes Delphi will just display "evaluating" and hang - the only thing I can do at this point is reset the program.
Does anyone know if there is a setting I can adjust to prevent this hanging?
Check these settings:
Is the ISAPI dll running in a separate dedicated Application Pool?
Is "Maximum Worker Processes" set to 1?
Is the "Identity" set to a normal user, preferably your own account or the account you run the Delphi debugger with?
(If the ISAPI dll is 32-bit running on a 64-bit server: Is "Enable 32-bits applications" set to "True"?)
Are limits, timeouts and intervals set high enough or disabled so IIS won't try to recycle the worker process while you're debugging.
Scenario:
Delphi ISAPI dll written using Delphi XE, 32 Bit.
ISAPI dll is running through IIS 7.5 on a Win 7 64 enterprise desktop
machine.
DLL runs fine.
Debug the ISAPI DLL in the Delphi XE IDE by using Run->Attach to
Process:
Launch the ISAPI DLL and attach to the wpw3.exe *32 process in the
debugger - can trace and debug code as it runs in the ISAPI context.
Problem:
My hard drive died last week and I got a new Win 7 installation - the
standard corporate wide Win 7 64 Enterprise image (not the same as my
previous Win 7 64 installation).
Now, when I go into Run->Attach to Process, I no longer see the
wpw3.exe *32 process by name, although it is visible in task manager
by name. Invoking the 'show system processes' option on the 'Attach to
Process' Dialog box does not help.
What I DO see now (which I never saw before in my old deployment) is
a long list of 'generic' System process with PID's but no
descriptions other than 'System'.
One of these processes is my wpw3.exe *32 process, and I have identified
its PID using MS's Process Explorer. But if I try to attach to
that process I get an error message - 'Cannot create process -
access denied' - so I can't debug. (Same error message 'Error
Opening process, Access denied' also shows in Process Explorer for
certain properties, although the descriptive name of the process '
wpw3.exe *32' is visible there, associated with the PID.)
How can I get the Run->Attach to process dialog box to display the
proper wpw3.exe *32 process name and attach to it, so I can debug?
Is this a Delphi problem? An IIS problem? An ISAPI problem? Is this one problem - ie lack of descriptive process name and inability to attach to process are caused by same problem; or is this two problems: one problem being lack of descriptive name, another the inability to attach to the process?
(Do not want to use - cannot really use - webApp debugger for this -
these are ISAPI dll's that are deployed to production exactly as they
are written and debugged in IIS - I need to see them running in IIS
context.)
Been debugging ISAPI dll's for several years this way, with different versions of Delphi and in various OS and server environments without any problems - never encountered this problem before. I am stumped.
My account has admin rights, but it hit me that I should try running DelphiXE as an admin – launch it with the ‘run as administrator’ option.
I got prompted ‘do you want to allow…’ – clicked yes and Delphi ran. Set up my process and hooked in and traced through my code - process names now visible and I can attach to my IIS process and debug in the Delphi Debugger.
I did not have to go through this step in my previous deployment, for whatever reason - but problem solved.
If you want to debug a 32 bit ISAPI dll on a 64 bit OS you can use the following process.
This assumes that you have followed other steps to allow 32 bit ISAPI dlls to work.
Stop IIS
net stop w3svc
Start the 32 bit worker process in debug mode
%SYSTEMROOT%\SysWOW64\inetsrv\w3wp -debug
Attach to the w3wp in the debugger. As you noted you need to be running Delphi with elevated privileges for this to work.
I never really got the chance to do anything with Microsoft ActiveX in all of my programming career. So, I have very little knowledge of what it is or what it is used for. Although I've searched on the Internet for answer, I found many different definition for ActiveX or ActiveX Container. One of my customer is asking for ActiveX Container for my software which I don't have. He wants view or take control of my software remotely through this ActiveX Container. Is this possible? Also, is ActiveX still around? I am trying to see if I can put this ActiveX container real quick for him to use.
I am assuming that ActiveX is used to expose some part of your software to the Internet or the Intranet. So, that the user can get access to your application remotely.
Any response will be greatly appreciated.
Thanks,
An Activex container is a frame where An ActiveX control can run, These containers can be embedded in a Desktop app or a Web page.
Due which the ActiveX control contains native code you must setup the security settings of your browser in order to run this kind of objects. The only browser where the ActiveX is fully supported is IE (exist some experimental projects to support Activex in Firefox and chrome) Also these containers only can run under Windows.
The fastest way to convert your existing app into a ActiveX Control , is using a TActiveForm (below you have a link with a sample).
For more information try these links
Introduction to ActiveX Control Containers
Wrapping a Delphi TFrame descendant as an ActiveX control
I'd like to build an out-of-process COM server with Delphi that does not need any visual forms. The main purpose of that server is to provide some "out-of-process" processing for other Windows Services.
Is it possible to place COM objects into simple console application? I expect it will (at least) need some kind of message-handling loop inside.
Can I place it inside of Windows Service instead?
You could do message handling yourself, but the Component Services tool in the Administrative Tools that are available in Windows, since Windows 2000 if I remember correctly, provides a way to select an ActiveX dll and have it run from a dllhost.exe process, optionally as an NT-service.
If you really want to you could start a plain exe project and add TAutoObject's to it, even to an NT-service project, but there's a little extra work to be done to get multi-instancing, security and concurrency right.
You can check SvCom for an explanation on what's different in running a DCOM server as a service, and for a library implementing it fully, supporting latest Delphi releases also.
I encouter problem with my application when it turn in PC running other application using same BDE as my application , my application can't store record in database in this case, is thre any configuration to make in BDE resolving this problem .
If you operating system is XP or Win7 try editing the BDE settings in BDE administrator in the control panel (backup you idapi.cfg first, of course!). Under configuration|system|init change the sharedmemlocation to 6BDE. Restart your computer.
This will allow BDE to be called by mulitple programs. It may allow the two programs to use the BDE.