Our KB article http://support.microsoft.com/kb/815112 clearly states this. Then, you may ask me “Why this guy is repeating the documented thing in this blog post ?”. Answer is simple, we do see lots of issues coming from our customers about this and I want to mention about this point in this blog too just thinking that I may prevent our developer community before designing their .NET apps with MSXML. Because we do see that some new .NET developers who are used to use MSXML before .NET wants to use those MSXML libraries.
Also you can ask us “if it is not supported why don’t you prohibit MSXML usage in .NET with someway?” . The short answer is “we cannot”. The long answer is liket that… Our MSXML (3,4,6) COM libraries are our COM libraries for you to use it in your non-.NET applications. Using COM libraries in a .NET app (we do call this as “doing COM Interop”) is not prohibited, but you should be careful which COM component you’re doing interop. You can write your own COM component and use/call it in your .NET app and it could work without issues. But as I said, it depends what does it do, especailly by means of “thread-safety”. 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.
So what should you do ? Simple. Use our System.Xml namespace there waiting for you to use in your .NET applications.
The similar situation applies for ADO Interop. Please refer to http://support.microsoft.com/kb/910696 . You’ll see that we do not say it’s not supported at all but there are lots of limitations.
Again, I want to remind that we have ADO.NET for you to use in your .NET applications.
Please do notice that your brand new fuel/electric hybrid car already has got a nice stereo with MP3/WMA XM Radio etc. playing capability and do not try to assemble your old old casette tape player to your brand new car 😉