2

I've seen a similar issue when using mshtml.dll referenced in our .NET projects, but nothing related to this specific situation. I'm suspecting the issue may have some relation to what was said in this thread (.net document write with mshtml) about the coclass missing in my case all related properties/attributes. The specifics here are that I'm using mshtml.HTMLInputElement and a set of its properties/attributes while parsing a WebBrowser.Document object:

if (domElement is HTMLInputElement)
{

  HTMLInputElement inputElement = (HTMLInputElement)domElement;

  if (inputElement.name == null || inputElement.name.Trim() == string.Empty ||
      inputElement.name.Contains("/") || inputElement.name.Contains("="))
  {
    ...

  }

}

The above works fine under a development PC (VS2008 3.5 SP1) where besides the name property some other are also being called successfully like type , etc.., but when the application is installed under Windows 7 which have all required framework pieces, I get the COMException:

==============

System.Runtime.InteropServices.COMException crossed a native/managed boundary Message=Member not found. (Exception from HRESULT: 0x80020003 (DISP_E_MEMBERNOTFOUND)) Source=mscorlib
ErrorCode=-2147352573 StackTrace: at System.RuntimeType.ForwardCallToInvokeMember(String memberName, BindingFlags flags, Object target, Int32[] aWrapperTypes, MessageData& msgData) at mshtml.DispHTMLInputElement.get_name()

======================

None of the calls to properties like name, type, are working now. Always the same Interop.COMException is being thrown. It sounds to me like the same problem explained in .net document write with mshtml.

Does anyone knows a valid workaround for this issue?

Community
  • 1
  • 1
rlazo
  • 21
  • 2
  • The presence of the late-bound mshtml.DispHTMLInputElement in the exception message is very hard to explain with that code snippet. – Hans Passant Feb 11 '13 at 23:48
  • if you open the metadata of HTMLInputElement you can see that it actually inherits/implements interfaces : DispHTMLInputElement, HTMLInputTextElementEvents_Event. So that's the reason why the DispHTMLInputElement appears in the snippet I entered above. – rlazo Feb 12 '13 at 15:31
  • 1
    ISSUE RESOLVED...Finally we were able to find the root cause of the issue we had posted above. It seems that under Windows 7 .NET 4.5 Framework, everything falls into the HTMLInputElement type SOMEHOW, I mean, the condition: if (domElement is HTMLInputElement) evaluates TRUE despite of the fact that the underlaying object IS NOT A REAL HTMLInputElement, and that is the reason why I got the COMException. Under WindowsXP .NET 3.5 SP1, the issue does not occur, a real HTMLInputElement is the only one that makes the condition to evaluate true. I don't know how microsoft allowed this to happen.. – rlazo Feb 12 '13 at 20:06
  • 2
    The solution here will be that instead of asking just for HTMLInputElement, we should also ask for IHTMLInputElement in our if: if(domElement is IHTMLInputElement && domElement is HTMLInputElement ) {..} This will avoid anything else from getting into the if block. Or it'll be better to ask ONLY for IHTMLInputElement within the if() statement..So DO NOT EVER use the IS operator against a concrete class type under 4.5 but it's safer to use it against the Interface instead. – rlazo Feb 12 '13 at 20:24
  • 1
    Thank you! I had this same problem, but with properties on `HTMLDocument` instead of `HTMLInputElement`. I switched to `IHTMLDocument2`, and it seems to be working. This also seems to be specific to some update to Windows or IE that was released, as I started getting this after applying updates. (It could be that I updated to IE 10.) And by "concrete types", I think you mean "concrete COM types from mshtml". – jpmc26 Oct 24 '13 at 21:06
  • Oops. Forgot the @user2062949 – jpmc26 Nov 01 '13 at 01:48
  • @jpmc26 thank you so much, solved the problem for us too. It was only on a specific prod env where it just wouldn't work, and your solution solved it for us. – omerts Jan 23 '17 at 20:45

0 Answers0