none
vb.net app (not sharepoint) receiving hresult exception 0x80020009 RRS feed

  • Question

  • I have a vb.net application that runs on systems with .net explicitly identified as installed.  On Windows 7 systems where the .net components are "imbedded" the application throws the following exception upon loading - exception from hresult 0x80020009 (DISP_E_EXCEPTION).  This is not a SharePoint application.  I am using the office.interop.excel.application, workbook, and worksheet components.  Monitor PVDG42 stated "the app cannot find .net components on Modern Windows systems where it is embedded in the OS".  I have to assume he is correct (he is more knowageable about this than I am) but I am not sure what the course of action is to resolved the problem.  He suggested that I rebuild the application on a Windows 7 system environment - the application was built on a Windows 7 environment using VS 2005.  I do not have the error on my system for VS 2005 "created" explict hooks to the .net components which of course seems to confirm PVDG2.  Is the real solution to move to VS 2010?  Any help would be greatly appreciated.


    Gordon Haas

    Thursday, February 9, 2012 7:25 PM

Answers

  • Thank you for your response.  I did indeed use that tool two days ago to verify that all components were in place and operating according to spec - a good tool.  As it turns out the problem is not in the domain of .net.  Once I had "compleltely" simulated the envrionment I discovered the real culprit - a printer definition.  The production environment was one of client:server and even though the vb code was being executed from the Server it came back to the client for the printer.  The test case that I created did not simulate the dual OS platform that was in production.  The work around that I had implemented in the production environment (to get around the ".net" issue) was to use RDP prior to executing the vb code so in essence collapsing the environment to a single OS platform!  Consequently, I found the problem by placing all components on the client system and then systematically drilling down to the "real" culprit.  By the way if you ever need to modify the .rdp file on the fly in order to pass parameters get ready for a "quark level" experience!!

    Respectfully,

    Gordon Haas


    Gordon Haas

    • Proposed as answer by pvdg42 Saturday, February 11, 2012 2:55 PM
    • Marked as answer by Alexander Sun Monday, February 13, 2012 5:57 AM
    Friday, February 10, 2012 2:44 PM

All replies

  • Hi Gordon,

    Welcome to the MSDN forum.

    Yes, the .NET Framework 2.0 SP2, .NET Framework 3.0 SP2 and .NET Framework 3.5 SP1 are embedded in Windows 7. To test if this error is related to .NET Framework setup, you can use .NET Framework Setup Verification Tool to verify the .NET Frameworks you have: http://blogs.msdn.com/b/astebner/archive/2008/10/13/8999004.aspx
     

    I hope this helps.

    Best Regards,


    Alexander Sun [MSFT]
    MSDN Community Support | Feedback to us

    Friday, February 10, 2012 6:29 AM
  • Thank you for your response.  I did indeed use that tool two days ago to verify that all components were in place and operating according to spec - a good tool.  As it turns out the problem is not in the domain of .net.  Once I had "compleltely" simulated the envrionment I discovered the real culprit - a printer definition.  The production environment was one of client:server and even though the vb code was being executed from the Server it came back to the client for the printer.  The test case that I created did not simulate the dual OS platform that was in production.  The work around that I had implemented in the production environment (to get around the ".net" issue) was to use RDP prior to executing the vb code so in essence collapsing the environment to a single OS platform!  Consequently, I found the problem by placing all components on the client system and then systematically drilling down to the "real" culprit.  By the way if you ever need to modify the .rdp file on the fly in order to pass parameters get ready for a "quark level" experience!!

    Respectfully,

    Gordon Haas


    Gordon Haas

    • Proposed as answer by pvdg42 Saturday, February 11, 2012 2:55 PM
    • Marked as answer by Alexander Sun Monday, February 13, 2012 5:57 AM
    Friday, February 10, 2012 2:44 PM