locked
Some types are not recognized in VB.net RRS feed

  • Question

  • User-1938843120 posted

    Hi! I'm writing a Web application, and I'm having two problems:

    1. I had references to Office 2003 dll so I added 2007, and deleted both in order to, later, add just the 2007 (I know, delete and then add, I know, it's stupid), and so I erase that assembly line from the Web.config. Now, when I add them, they do not apper on the BIN folder :S

    2. Now, in the App_Code folder I notice types as Exception, or functions like Ch are not recognized! Is that normal? How can I fix this?


    Tuesday, May 25, 2010 7:51 PM

Answers

  • User-952121411 posted

    Anyway, I realized that when the Task Manager showed like 20 EXCEL.exe applications running.
     

    This is only 1 of the many frustrations that occurs from improperly closing the unmanaged Excel COM object in code. It is crucial that you get Excel to close properly or this will continue to happen. You will see many, many instances of Excel appear in Task Manager on Windows.  It is even worse when it happens on a production server.  Many times these errors are related to a DCOM configuration on the server, improperly installed Office version, not enough permissions, bad code, etc.   Most developers get everything working with ASP.NET and Excel on their development machine, only to become frustrated when posting out to the server and not having it work again.  The last advice again: be overly cautious when thinking about using Office Automation on the server for an ASP.NET application.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, May 28, 2010 9:33 AM

All replies

  • User-952121411 posted

    1. I had references to Office 2003 dll so I added 2007, and deleted both in order to, later, add just the 2007 (I know, delete and then add, I know, it's stupid), and so I erase that assembly line from the Web.config. Now, when I add them, they do not appear on the BIN folder :S
     

    The Interop Office .dlls are a pain to work with and often cause this confusion.  I try not to get within 10 feet of the things and avoid Office Automation in ASP.NET when possible.  And on this note, be sure to read the following:

    Considerations for server-side Automation of Office:

    http://support.microsoft.com/kb/257757

    Now I know sometimes it is a must, so let's try to fix your issue.  1st and foremost remove all Office .dll references by deleting them as you have done.  Then either do a 'Clean' of the solution or just delete the /bin associated with the project all together.  This ensures there are no lingering old .dlls.   Then re-add the 'correct' Office .dlls you need to your application and do a rebuild.  Verify the Interop .dlls get added to your /bin of your project by navigating to the location in Windows Explorer and making sure the correct version is there.  The exact version of Office must also be installed on the Server where the ASP.NET app is deployed, which can become a sync nightmare too between Office versions.  And to top it off, it seems that Excel code behaves differently between Office .dll versions, so once you get it working try to stay with those .dll versions.

    2. Now, in the App_Code folder I notice types as Exception, or functions like Ch are not recognized! Is that normal? How can I fix this?

    'Ch' isn't a valid .NET type that I am aware of in VB.NET.  If you mean 'char' that is in the default namespace and should be recognized.  Try looking at your 'Errors' tab in VS.NET and read the message.  It may tell you if references to the project are missing.  If the project gets too messy, sometimes I start by creating a new project in VS.NET, and then slowly adding back existing items from the old project, making sure the app build along the way.

    Hope this helps! Smile

    Wednesday, May 26, 2010 11:30 AM
  • User-1938843120 posted

    Hi!

    It really did. However, the dlls do not appear int he BIN folder now :S

    And, now I'm getting the following error:

    Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following error: 80080005

    Whereas it used to work before. I have read that it has something to do with registering the DLLs on the server. What I don't understand is why this wouldn't work... I just want to create a file on the server and send it to the client. Right now, I'm just creating a blank file to see if it works. Weird thing is, it used to... Do you know what can be causong this?


    BTW, this application won't go online, it'll run on the intranet, so I think there won't be much security issues. Do I have to go and mess up with the server? Right now I'm woriking on a local machine with access to the code in the server, but I can't change its settings from here.


    Thanks in advance

    Thursday, May 27, 2010 12:28 PM
  • User-952121411 posted

    Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following error: 80080005
     

    Yeah I have worked with a few people that had a nightmare when moving up to Office 2007 with Excel Interop and were receiving issues similar to those.  The user I worked with ported the Excel data into an ADO.NET object and then used LINQ against it to bypass Excel completely.  In your case if you must use Office Automation on the server, you are going to have to work through these issues 1 by 1.  Here is a link, with a similar error that may help.

    http://blog.crowe.co.nz/archive/2006/03/02/589.aspx

    I have seen developers pull their hair out too because the Office Automation works on their machine but not on the deployed server.  My advice, steer clear of Office + ASP.NET if at all possible.  If you have to have Office Automation, consider using another app type like WinForms or WPF that handle those operations on the client rather than on the server.

    Thursday, May 27, 2010 4:23 PM
  • User-1938843120 posted

    Mi first problem was just that the dlls didn't appear in the bin folder. Back then, I could create an Excel file and all; but when I erased them and did a rebuild, this error started appearing.

    The thing is... Having me erased the dlls (now I put them back on) could have affected it? I mean, it was working until that point...

    Thursday, May 27, 2010 4:47 PM
  • User-1938843120 posted

    ANSWER!!!

    Well, it seems I wasn't properly closing the files when exceptions arose... So, that very-much-no-significant exception was due to my poor exception handling. Wonder how much people have changed their DCOM settings because of this.

    Anyway, I realized that when the Task Manager showed like 20 EXCEL.exe applications running. Hope this helps someone!

    Thursday, May 27, 2010 6:06 PM
  • User-952121411 posted

    Anyway, I realized that when the Task Manager showed like 20 EXCEL.exe applications running.
     

    This is only 1 of the many frustrations that occurs from improperly closing the unmanaged Excel COM object in code. It is crucial that you get Excel to close properly or this will continue to happen. You will see many, many instances of Excel appear in Task Manager on Windows.  It is even worse when it happens on a production server.  Many times these errors are related to a DCOM configuration on the server, improperly installed Office version, not enough permissions, bad code, etc.   Most developers get everything working with ASP.NET and Excel on their development machine, only to become frustrated when posting out to the server and not having it work again.  The last advice again: be overly cautious when thinking about using Office Automation on the server for an ASP.NET application.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, May 28, 2010 9:33 AM