Patrick,

> Beside the usual problems raised when using non managed code from .Net, 
I am aware of no such problems, related to COM interop (calling DLLs 
directly is antoher thing - you have to get the signatures right.)

> But why would you want to use MSXML from .Net code in the first place? 
I am workin on a large .NET code base, which has to use a component, that 
provides me with functionallity, that is not included in .NET framework. This 
component also runs on client systems, that do not have .NET framework 
installed (and we can not force  the users to do so).

The COM component uses MSXML internally, but also exposes some of the MSXML 
interfaces through its properties.

Thank,
  Matej



"Patrick Philippot" wrote:

> Hi Matej,
> 
> > It states: "Using MSXML in .NET applications through COM
> > interoperability can result in unexpected and problems that are
> > difficult to debug."
> >
> > If I undertand the article, it means "it will not work fine". I am
> > trying to find out what can go wrong.
> 
> Beside the usual problems raised when using non managed code from .Net, 
> it seems that there are also MSXML implementation related problems that 
> could cause trouble. So if they say, don't do it, don't :-) . Especially 
> in production code.
> 
> But why would you want to use MSXML from .Net code in the first place? 
> There is more useful classes and tools in the Xml namespace than you can 
> expect from the MSXML component. The only "problem" is that SAX is not 
> supported and replaced with the more useful XmlReaders, based on the 
> Pull Model. If you absolutely want SAX, you can simulate it by using the 
> ..net classes.
> 
> -- 
> Patrick Philippot - Microsoft MVP
> MainSoft Consulting Services
> www.mainsoft.fr 
> 
> 
>