Accessing ActiveX EXE from ASP:

im relatively new to the vb world, but i worked a lot with asp and vbscript, so at least im not a complete fool when it comes to vb syntax.

ive created an activex exe that i want exposed to an asp application. the asp program will modify values in the activex component, and those changes will automatically appear in the exe's form. pretty common right? the problem i am coming across is this:

when i execute the exe to initialize it, it creates a process, as displayed in the windows taskbar. fine. but when i try to access the component via asp, i see another process being initialized in the taskbar - therefore when i make changes via asp, they do not show up in the exe that i had originally started up (since they are each in different processes, i assume). is there a setting that i am missing which will eliminate this?

thanks,
flashboy.

ActiveX .Exe's run out of process by design. Each caller will essentially create a new process with each call. You start the .exe, that's one process. However you got asp to start the .exe, that's the second process. You never want to allow ASP to run .exe's on your server. This is a basic security precaution, disallowing the iusr account to run executables is a default with IIS and should not be altered. Regarding ActiveX technology, generally ASP/IIS apps should only be interacting with ActiveX DLLs and not EXEs. Not the answer you were probably looking for but no good IIS/Web developers would consider creating such unstable, unsecure apps.

thanks,

i think im starting to understand the whole thing about in-process vs. out-of-process.

but im a little confused because ive downloaded a handful of vb source code samples of application servers, and they seem to imply that the ASP code can interact with an EXE that has already been initialized (ie. they all interact within the same process)

one program that i am looking at in particular is here:
http://www.planet-source-code.com/vb...12237&lngWId=1

I downloaded the code from the link you supplied and walked through it. Nothing offered by this code is any better than writing good ASP code with or without using ActiveX Dll's. The benefits the author lists by using his activex exe solution are no better and actually bad solutions to what he claims are good reasons to use the framework.

He claims his framework will allow the programmer to tap into realtime graphs, maps, or whatever. In reality, it's gonna take longer to instantiate and pass all of the IIS objects to his "application server" than to simply generate and display the graph using in-proc com dll's.

All objects are passed first of all byref, which means two network round trips for each object passed(bad bad bad).

Since it's an Exe it cannot take advantage of any COM+ features as only Dll's can be registered in COM+.

Another benefit he lists is being able to write directly to the Response object, read directly from the Request object, blah blah blah. How frickin ridiculous is this? you do that right off the bat with straight asp, but using this code you first pass the objects to the activex exe. Next, for some reason he makes a copy of them in module level variables, then writes "directly" to his _copy_ of the actual object.

This is horrible code and should be avoided at all cost. That's my two cents.

hmm... i think you made some very good points there.

im curious, when you ran the program and tested it using the ASP page as your input form, did your "banner" text that you entered show up in the running exe? for me personally, it did not, but i got the impression that it was supposed to - thereby demonstrating the ability to expose the com interface of a running exe to an ASP page.

the reason i am so hung up on using an activex exe is because i need a vb component (or service) that services winsock connections to multiple clients (the clients are built in flash - using an XML socket). but i also need to account for users who do not have the flash plugin installed, and thus they need to have access to the component via ASP. of course, they will not have a socket connection to have data "pushed" out to them, but they will at least be able to grab some data from the vb component every once in while. does this make sense?

the other alternative (seeing as how few responses i am getting on this matter in other forums) i am considering is splitting up the component into 2 piececs - a winsock server activex exe component, and a activex dll component. users who are able to connect via winsock can go directly to the activex exe, while those using asp will first go to the activex dll's, which will then in turn access the activex exe (this is possible, right?)

if you have any thoughts/criticism, please let me know. thanks again!

:)