.net document write with mshtml

Question

I am using mshtml for html parsing. (version 7.0.3300.0, C:\Program Files\Microsoft.NET\Primary Interop Assemblies\Microsoft.mshtml.dll).

HTMLDocumentClass have a write method so i used it but it raises ComException with ErrorCode:-2147352571 and Message:Type mismatch. What is the reason for it? If write method of HTMLDocumentClass will not be used why did they define?

    HTMLDocumentClass getHTMLDocument(string html)
    {
        HTMLDocumentClass doc = new HTMLDocumentClass();

        doc.write(new object[] { html }); // raises exception
        doc.close();

        return doc;
    }

    HTMLDocumentClass getHTMLDocument2(string html)
    {
        HTMLDocumentClass doc = new HTMLDocumentClass();
        IHTMLDocument2 doc2 = (IHTMLDocument2)doc;
        doc2.write(new object[] { html });
        doc2.close();

        return doc;
    }

Rodman

Don't. Instead, use htmlagilitypack.codeplex.com. – Labile

+1 on HtmlAgilityPack. It THE solution to use for all your HTML parsing needs. – Solubility

so, i just not looking for a parsing solution but want to know if i am missing something about interfaces and com objects. – Rodman

This is very hard to explain. Using doc.IHTMLDocument2_write() works fine. Almost quacks like a bug in the PIA, hard to believe. Using the interface is however always recommended, especially for VS2010 with its Embed Interop Types feature. – Conde

I found HtmlAgilityPack to fail on many occasions and frankly got dissapointed with it. It broke initial htmls, whenever it had not closing tags for some elements and those don't have to be closed by specification (td, li and others). – Siracusa

Answer 1

Okay, I found it. This is an interesting failure mode. All of the PIAs for Microsoft.mshtml that I have installed on machine are outdated. No less than 4 of them, all version 7.0.3300.0 with a runtime target of 1.0.3705 (which is quite old).

The fooClass interop class that's generated by the type library importer is the cause. It is a synthetic class, it exists to make events a bit easier to deal with, they are done very differently in COM. The class is a flattened version of all of the combined methods of all interfaces. The current SDK version of the HTMLDocument coclass is declared as follows (from mshmtl.idl):

[
    uuid(25336920-03F9-11cf-8FD0-00AA00686F13)
]
coclass HTMLDocument
{
    [default]           dispinterface DispHTMLDocument;
    [source, default]   dispinterface HTMLDocumentEvents;
    [source]            dispinterface HTMLDocumentEvents2;
    [source]            dispinterface HTMLDocumentEvents3;
                        interface IHTMLDocument2;
                        interface IHTMLDocument3;
                        interface IHTMLDocument4;
                        interface IHTMLDocument5;
                        interface IHTMLDocument6;
                        interface IHTMLDOMNode;
                        interface IHTMLDOMNode2;
                        interface IDocumentSelector;
                        interface IHTMLDOMConstructor;
};

If you use Object Browser on the interop library, you'll see that HTMLDocumentClass is missing the interface methods for IHTMLDocument6, IDocumentSelector and IHTMLDOMConstructor. The write() method you are using is past these interfaces.

Which means that if you use HTMLDocumentClass.write(), you'll call the wrong method. The exception is raised because whatever method is being called isn't happy about the argument. Of course it is not.

This is a nasty failure mode of course. This came about because Microsoft broke a very hard COM requirement, changing a COM interface or coclass requires a different guid. The [uuid] attribute in the above declaration. That however also makes new versions of Internet Explorer completely incompatible with old code that uses it. Rock and a hard place, backwards compatibility is quite sacred at Microsoft. The order of interface implementations in a coclass is not normally a problem in regular COM clients. Except in .NET, it breaks the layout of the synthetic XxxClass type that tlbimp generates.

I've never seen a case where that synthetic class was actually required and never use it myself. You can always obtain the correct interface pointer by casting in C#, that calls QueryInterface() and always returns the correct pointer regardless of the version. Your alternative is the proper workaround.

Conde

so, i add a reference to the c:\windows\system32\MSHTML.dll that its HTMLDocumentClass contains interface methods for IHTMLDocument6,IDocumentSelector and IHTMLDOMConstructor. But it raises the same error when write method used? – Rodman

i determined(by Reflector) that also WebBrowser controls Document(HtmlDocument) write method also calls IHTMLDocument2's write method. – Rodman