locked
Developing a Windows Service - Getting a COM not registered problem RRS feed

  • Question

  • Hi, I'm hoping to find some help.  I'm having zero luck searching for an answer so far...

    I'm writing a Windows Service.  I'm trying to get it to use our in-house business objects DLL (which provides document structure, database access, etc.).  I'm also accessing a current Windows Desktop application I've written (which provides for emailing groups with little coding in the service and also uses our business objects as a reference).  I've included the business objects DLL and the application EXE in the references for my service.

    My Windows Service, the application and the business objects DLL are - Under "Advanced Compiler Settings" - set to: Targer CPU: x86.  I've been reading that this setting should make the problems go away.  It has not.

    The setting for "Target framework (all configurations):" is set to: .NET Framework 4 (for all three projects).

    Despite using what I've read and chaning the settings, when I debug my Windows Service by attaching a process and setting break-points, when the debugger hits its breakpoint, our business object gives me the following error:

    Retrieving the COM class factory for component with CLSID {#} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).

    This error is preventing me from connecting to the code from my desktop application as my desktop application which would give me access to our database and allow me to send emails with just a couple lines of code.

    Since I've started seeing this problem in my Windows Service, I've begun to notice that if I open up another visual studio GUI and look at desktop application, my form designer won't display the form, it too now has an error (the same as the one listed above) that prevents the form from displaying visually. 

    Has anyone ran into this?  I've been chasing this problem for the better part of 2 days, and have made very little progress. 

    Wednesday, June 12, 2013 2:50 PM

Answers

  • So it would seem with our business objects DLL, it just sits in a specific drive and folder, and the users (programmers that need its functionality) add the DLL as a reference in their projects. 

    We also have to be careful with our references to projects because my project reference includes a reference to the business object DLL also.  And when the references are different it causes problems as well. 

    I have since successfully changed the exe project to reference the correct business object dll (before I was referencing the business object project - the project and the "current" DLL were at odds because they had different versions), and now both the exe reference and the business object DLL are the same version.

    It would seem that I have fixed the COM error by getting the references aligned and pointed at the same DLL. 

    Thanks

    Thursday, June 20, 2013 3:55 PM

All replies

  • How is your business dll registered? regasm? Use procmon to log the file/registry activity to ascertain your dll is loaded correctly. Also check if you COM server can throw any exception during initialization.



    Visual C++ MVP

    Thursday, June 13, 2013 7:52 PM
  • As Sheng asks, how exactly did you register the Dll?  The registry view of a service running with the local system account is not the same as the view of a program running with a user account.

    See this:

    http://msdn.microsoft.com/en-us/library/windows/desktop/ms724475(v=vs.85).aspx

    and note the difference between HKEY_CLASSES_ROOT and  HKEY_LOCAL_MACHINE\Software\Classes for the non-interactive user like your service.

    This is a long shot, but if your service is running x86 and you can run regedit in your interactive user context and see the registration in HKCR, perhaps check the Software\Classes\Root key. Sheng's suggestion of monitoring is excellent because you should see whatever redirection is happening and diverting to an absent registry item.


    Phil Wilson

    Thursday, June 13, 2013 8:43 PM
  • So it would seem with our business objects DLL, it just sits in a specific drive and folder, and the users (programmers that need its functionality) add the DLL as a reference in their projects. 

    We also have to be careful with our references to projects because my project reference includes a reference to the business object DLL also.  And when the references are different it causes problems as well. 

    I have since successfully changed the exe project to reference the correct business object dll (before I was referencing the business object project - the project and the "current" DLL were at odds because they had different versions), and now both the exe reference and the business object DLL are the same version.

    It would seem that I have fixed the COM error by getting the references aligned and pointed at the same DLL. 

    Thanks

    Thursday, June 20, 2013 3:55 PM