locked
Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following err RRS feed

  • Question

  • Hi all

             Microsoft.Office.Interop.Outlook.Application objOutlook;
            Microsoft.Office.Interop.Outlook.NameSpace objNamespace;
            Microsoft.Office.Interop.Outlook.MAPIFolder objMAPIFolder;
            Microsoft.Office.Interop.Outlook.MailItem objItem;
            Microsoft.Office.Interop.Outlook.UserProperty objProp;

    I use this piece of code to generate new message Outlook window

    I am using the reference Microsoft.office.Interop.Outlook,version=11.0.0.0 from the Product Microsoft office 2003
    It works in fine in development System
    When I Install my application in the clinet machine ,where I dont have Microsoft office 2003
    So It throws

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


    Still I can Find the Microsoft.office.Interop.Outlook,version=11.0.0.0  in the GAC
    What is the cause
    How Can I resolve this ,With out Installing Microsoft office 2003 in the Client machine

    Any help is Greatly Appreciated




    Thursday, September 11, 2008 9:12 AM

Answers

  • Hi,

     

    The interop assemblies are just managed wrappers around COM interfaces.  They don't provide any implementation; they are just pass-throughs to the COM server itself--which in this case is Outlook.  In order for your code to run, Outlook 2003 or greater must be installed on the machine.

     

    Sincerely,

     

    Geoff Darst

    Microsoft VSTO Team

     

    Thursday, September 11, 2008 3:12 PM
    Answerer

All replies

  • Hi all

             Microsoft.Office.Interop.Outlook.Application objOutlook;
            Microsoft.Office.Interop.Outlook.NameSpace objNamespace;
            Microsoft.Office.Interop.Outlook.MAPIFolder objMAPIFolder;
            Microsoft.Office.Interop.Outlook.MailItem objItem;
            Microsoft.Office.Interop.Outlook.UserProperty objProp;

    I use this piece of code to generate new message window

    I am using the reference Microsoft.office.Interop.Outlook,version=11.0.0.0 from the Product Microsoft office 2003
    It works in fine in development System
    When I Install my application in the clinet machine ,where I dont have Microsoft office 2003
    So It throws Assembly missing Exception


    How Can I achieve this ,With out Installing Microsoft office 2003 in the Client machine
    Thursday, September 11, 2008 5:44 AM
  • Unless we're talking 2003 to 2007, you can't. The Office type libraries are version specific and, at best, may support bringing code forward to a newer version. See the following forum message threads:

     

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3037862&SiteID=1

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3276675&SiteID=1

     

    Thursday, September 11, 2008 1:49 PM
  • Hi,

     

    The interop assemblies are just managed wrappers around COM interfaces.  They don't provide any implementation; they are just pass-throughs to the COM server itself--which in this case is Outlook.  In order for your code to run, Outlook 2003 or greater must be installed on the machine.

     

    Sincerely,

     

    Geoff Darst

    Microsoft VSTO Team

     

    Thursday, September 11, 2008 3:12 PM
    Answerer
  • Thanks for the Reply Guys

    What is the use of office PIA 2003 ,B'cause I am very new bee to this tech,I can find some help online but Little bit confusing to understand the concept of PIA

    Regards
    DAM
    Friday, September 12, 2008 5:18 AM
  • Hi DAM

     damu maddy wrote:
    What is the use of office PIA 2003 ,B'cause I am very new bee to this tech,I can find some help online but Little bit confusing to understand the concept of PIA

     

    The Office object models are COM and use COM type libraries. COM bases on different concepts and rules than the .NET Framework, so COM type libraries and .NET can't "talk to each other" directly. (Think of it as two people who grew up speaking different languages, from very different cultures.)

     

    In order for a COM type library to "talk" to .NET an interpreter is required. This is the function of the IA (Interop Assembly).

     

    In Visual Studio you can access any registered COM type library through the COM tab of the "Add Reference" dialog box. If there's no IA registered in the GAC Visual Studio will invoke the tool TlbImp (Type library import). This tool analyzese the COM type library and provides an interface to it that .NET understands and can work with, then stores it as an IA in your solution folder. (Think of TlbImp as a very smart WorldLingo kind of thing - what it produces is useable, but not always perfect.) The code in your project "talks" to the IA, which translates the .NET concepts into things the COM type library understands; it also takes care of passing back info generated by the COM type library to your project in a form .NET can work with.

     

    A PIA is a "Primary" Interop Assembly. A PIA has been manually optimized to clear up ambiguities and any problems the automatic generation of the IA has introduced. (Like a human translator cleaning up a machine-generated translation.) PIAs are almost always installed in the GAC to ensure global use of them by all developers.

     

    Example of IA vs PIA: If you ever encounter any documentation that discusses automation of Word 2000 as well as later versions you'll find code snippets that are different for Word 2000. That's because there are no PIAs for Word 2000, only for 2002 and later. Word 2000 automation solutions rely on a TlbImp-generated IA, which is not opitimized, thus different syntax is required for some things.

    Friday, September 12, 2008 8:33 AM
  • Actually, a PIA is just a "blessed" version of an interop assembly.  The only thing that distinguishes a PIA from a regular interop assembly is that PIAs are so designated by a  registry key which is associated with the corresponding type library.  While Office PIAs my be generated differently and/or hand-tweaked, that is not a requirement.  Most PIAs are generated directly from TLBIMP.EXE.  Because they are a shared component, PIAs are installed in the Global Assembly Cache.  Any interop assembly (however it was created) can be designated as a PIA, but there can be only one PIA to represent a given COM type library.

     

    The reason we have PIAs is this: types are always assembly qualified.  In the case of COM types, if the same type exists in two different assemblies, the Common Language Runtime (CLR) will treat them as different types--even though from a COM perspective they are the same.  This creates problems when two different assemblies reference their own interop assemblies.  In that case, they cannot pass common COM types between them.  For example, say I were to create a class library that exposed a method which took a Word Application interface reference as a parameter.  You might have an existing application that talks to Word via your own interop assembly.  When you go to consume my class library, you attempt to pass a Word Application instance that you had already obtained through your interop assembly.  Unfortunately, when you go to compile you find out that the CLR treats your version of Word.Application and my version of Word.Application as two different types.  The only way to enable the consumption of my class library would be for you to recompile your application using my interop assembly.  However, once a second class library from a different vendor with yet another interop assembly is introduced into the mix, things break down completely.  At that point, you have no way to unify the three components under the same interop assembly. 

     

    To solve this problem, we introduced the concept of PIAs.  This puts the onus on the owner of the COM component to provide (and distribute) a single version of an interop assembly that everyone is expected to use.  So in the example above, all three of our components would have been built against this single interop assembly which would enable them to interoperate with each other.

     

    For reference material on PIAs, see the MSDN documentation here: http://msdn.microsoft.com/en-us/library/aax7sdch.aspx

     

    Sincerely,

     

    Geoff Darst

    Microsoft VSTO Team

    Friday, September 12, 2008 3:26 PM
    Answerer
  • Thanks Cindy and Geoff

    For the reply ,Great work


    Cheers
    DAM
    Saturday, October 4, 2008 10:01 AM