--- "William A. Rowe, Jr." <[EMAIL PROTECTED]>
wrote:
> Can I suggest something? Try uninstalling the
> package you downloaded as .msi.
> ...
Bill,
Unfortunately, even if I tried to be precise and
cautious with building, registering and unregistering
sequence, the problem remains.
I used ILDASM on Apache.Web.dll and have some findings
to report that may help solving it.
ILDASM shows that compiler had no problem with
constructing CLI type for request_rec. It is
sequential value type and its layout is available in
httpd.h. ILDASM also shows its members like
apr_table_t *headers_out accessed by IL instructions
by offsetting from the beginning of request_rec
structure.
Since CLR fails trying to load
Apache.Native.apr_table_t type the question I asked
myself was:what causes the need to know the
type?Managed code clearly can not access apr_table_t
internals any more than Apache client code, that is,
with the exception of apr_tables.c which exposes
functions to manipulate this otherwise opaque
structure.
So I assumed that problem is caused by native
(unmanaged) functions called from managed code. ILDASM
shows native apr_table_elts() and apr_table_setn()
accessing value type Apache.Native.apr_table_t through
the pointer.
My guess would be that, because of this, marshalling
code wants to pass the copy of the value back and
forth between the managed and unmanaged code and, to
do that, it must know how to marshall it, for ex. by
knowing apr_table_t's layout and size.
Whether this interpretation is correct or no, after
commenting out all calls to apr_table_elts() and
apr_table_setn() in WorkerRequest.h and cpp I am not
getting errors for apr_table_t type anymore. CLR is
now trying to load type information for
Apache.Native.apr_bucket_alloc_t, like in previous
post, but where this problem was circumvented using
dirty trick of making apr_table_t internals known to
CLR.
ILDASM shows 17 native functions that use various
opaque types (apr_bucket_flush_create, apr_pmemdup,
etc.) so I am hoping that we can come up with some
glue code that won't 'provoke' CLR to want to know
their internals.
Tony
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com
