Interop between MSXML and .Net using COM+

Question

I need to create a .Net C# component with these two requirements:

Giving an XML and an XSL path as input parameters should return an HTML string.
The XSLT engine needs to be implemented using the MSXML XSLT processor ^*

Using MSXML via COM Interop could be an option but I've found this scary knowledge base article on the subject that says:

815112 INFO: Use of MSXML is Not Supported in .NET Applications
http://support.microsoft.com/kb/815112

MSXML uses threading models and garbage-collection mechanisms that are not compatible with the .NET Framework. Using MSXML in .NET applications through COM interoperability can result in unexpected problems that are difficult to debug.

Could using MSXML in out-of-process COM+ package be a safer way to access MSXML from a .NET application?
As stated in my requirements, I don't need to handle MSXML classes or interfaces as Input/Output parameters but just plain vanilla strings.

^{* The code base consists of thousands of XSL files that run fine on MSXML XSLT engine (MSXML 4.0) but give more than an error with the pickier System.xml .Net library.}

I don't understand why not use one of the builtin xml libraries? You're saying that system.xml is given you trouble. Perhaps it would be easier to debug the problem you are having with System.Xml. Alternatively couldn't you "preprocess" the files if you are having (most likely) formatting issues? — Maxim Gershkovich
I agree 100% with @MaximGershkovich- I can't help but imagine that fixing your problem with the built-in XML libraries will result in a vastly more stable and better-performing codebase. — Chris Shain
@systempuntoout what error? XML/XSLT is a very well-defined system- you shouldn't be seeing variation between the libraries. It's not that we are trying to be unhelpful- more like trying to point you in the direction of the elevator instead of the stairs. — Chris Shain
@Chris you shouldn't be seeing variation between the libraries - welcome to the real world — systempuntoout

casperOne casperOne · Accepted Answer · 2012-04-02T16:29:21

Yes, you can create an out-of-process COM+ application and then use the classes in the System.EnterpriseServices namespace or a WCF (I'd go with this, personally) to connect to the COM+ application.

Of course, this means you'll have to use some other technology besides .NET to host your component, but it's probably the easiest way to get process isolation and interoperability with .NET out-of-the-box.

Interop between MSXML and .Net using COM+

1 Answers