Hi

Based on my research, we did not recommend use MSXML in .NET application,
because there is a great XML class in .NET.
As for the problem if we can indirectly use MSXML in .NET. That is commonly
the scenario that the existing legacy COM project which underlying used
MSXML and now we wants to use it in .NET.

In such scenario, we recommend put the COM in COM+ and use it from .NET.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi Peter,

Thanks for your response. The situation is as you describe: we have a native
C++ COM component that makes extensive use of MSXML, and need to use this
from the .NET environment. We can modify the library so that we don't need to
instantiate MSXML objects in .NET or marshall MSXML pointers across the
interop boundary, but re-writing the library to use the .NET XML API is not
possible!

If I understand correctly, you're saying that we should run this component
in a separate process rather than as an in-process server? This is obviously
not ideal from a performance perspective.

I understand that the issue is to do with the MSXML garbage collector. Are
there any workarounds that would allow us to use our component in-process
within .NET? For example, how about if our component is only accessed from
unmanaged (un-garbage collected) MC++ types, via an MC++ wrapper?

Thanks for your help.

Regards,

David Coghlan

[quoted text, click to view]