Hi Tripp,
Allowing out-of-process components to run with IIS is pretty tricky - there
are specific permissions that need to be enabled because it's a huge
potential security loophole.
From memory you need to fiddle with the IIS metabase to enable this - it's
the sort of thing that is undoubtedly documented somewhere, but don't ask me
where!

In general, DLLs that don't know about IIS are pretty tricky to get working
in ASP too. There may be permission problems : does the IUSER_XXX account
have execute permissions on the directory the DLL is in, that sort of stuff.

Worst of all is when development is over, and you try to move it to a secure
production environment... Good luck.
Alistair


Original message :
Subject: Re: Mixed component environment problems
From: "Tripp Bishop" <dyne_erg@y...>
Date: Wed, 27 Mar 2002 18:05:24
X-Message-Number: 17

John,

first off, did the timer thing work for you?

OK, basically I've got an ActiveX dll, let's call it GeoCoder. GeoCoder is
registered on the web server and is NOT installed as a COM+ package. There
are ASP pages that make requests of the GeoCoder object.

Now, the Geocoder object is really nothing more than a pretty wrapper for
an old sinlge-threaded windows api dll, called mm32v7.dll. This object
does the real work for the geocoder object.

There is another ActiveX dll, called BoundaryFile that has a similar
configuration to GeoCoder. It makes use of an older ActiveX EXE.

What happens is that when a call is made to the BoundaryFile object, the
system loads a new instance of dllHost.exe and then the BoundaryFile
object just hangs (the ActiveX exe will not instantiate properly and
doesn't die gracefully so the thread/process hangs).

I need to find out if Microsoft has any information about how to set up
these sort of configurations so that the objects cooperate with each other
and work gracefully. Unfortunately for us, the active exe is a third party
component, so we don't have much control over how it behaves.

Is this clear?

Thanks again,

Tripp