COM Interop -- Class Library vs. EXE

[Gregory Hassett]

Hello,

I am developing classes in C# that are called from PHP via COM. The C# code
does a lot of work to establish internal data structures, and I would like
these data structures to persist so that I do not have to recreate them each
time the COM code is called.

For example, imagine a function MyObject.BuildInternalDataStructures() which
takes a long time. Another function, MyObject.UseInternalDataStructures(),
is called repeatedly. The first time UseInternalDataStructures is called,
it detects that the structures haven't been built, so it calls
BuildInternalDataStructures. Subsequent calls to UseInternalDataStructures
do not need to incur the penaly of building the internal data structures.

The problem is that on my web server, PHP instantiates a new instance of my
object each time a PHP page is hit -- and destroys the object (and unloads
my DLL) when the page completes executing. So the next time the user hits a
PHP page that calls out to MyObject.UseInternalDataStructures(), it has to
rebuild everything again from scratch.

Is there a way to build a COM server as an EXE, so that it can run in the
background, maintaining its state, while allowing COM consumers (such as
PHP) to call into it?

Thanks

Greg

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

The problem is that on my web server, PHP instantiates a new instance of
my
object each time a PHP page is hit -- and destroys the object (and unloads
my DLL) when the page completes executing. So the next time the user hits
a
PHP page that calls out to MyObject.UseInternalDataStructures(), it has to
rebuild everything again from scratch.

Does it unload the dll? That seems like very inefficienty ! , imagine 100
requests each loading/unloading the same dll

Is there a way to build a COM server as an EXE, so that it can run in the
background, maintaining its state, while allowing COM consumers (such as
PHP) to call into it?

First of all I would check in the unloading matter, it should be
configurable somehow.

If not possible then what you could do is using another process to hold the
internal structures, then the dll can communicate with it using remoting for
example. In anyway it would be less efficient.

 

[David Browne]

Hi,



Does it unload the dll? That seems like very inefficienty ! , imagine 100
requests each loading/unloading the same dll

I agree. It is much more likely that your objects are destroyed, but your
DLL is not unloaded. This is how ASP.OLD worked. If this is the case you
have static scope to store data between calls. Just be sure to make access
to static resources thread-safe.

David

 

[Nicholas Paldino [.NET/C# MVP]]

Gregory,

I think it is a simple matter of moving your data structures to a static
variable. Once the CLR is loaded, it is not going to be unloaded for the
life of the process (or at least, it shouldn't). Just make it static.

And if you find that the CLR is being unloaded, then I would create a
class derived from ServicedComponent which uses object pooling. You can
then create a pool of your objects, and incur the cost of initializing your
data structures on construction of your object.

Hope this helps.