none
Installing PIA does not register OutlookViewCtl RRS feed

  • Question

  • Hello everyone,

    I have developed an Outlook 2007 addon with Visual Studio 2008.

    For my deployment method I have chosen:

    1. Active Directory-assigned packages to all Windows 7 computers (I only deploy to Win7 machines) of

     - Office 2007 PIA
     - VSTO 3.0 Runtime

    2. ClickOnce installation of the addon itself, to benefit of

    - no admin rights required for the installation
    - built-in update mechanism for new versions of the addon

    My addon works perfectly except for one form that contains an OutlookViewCtl control.

    When the user tries to bring up the form, an exception is thrown "Class not registered".

    I assume that the class that is not registered is OutlookViewCtl 's class. After all, the form only contains two Windows.Forms.Radiobutton controls and the OutlookViewCtl.

    As I understand, the proper installation of OutlookViewCtl is the responsibility of Office 2007 PIA.

    The installation package of Office 2007 PIA was constructed by me following the exact instructions of http://msdn.microsoft.com/en-us/library/cc563937(office.12).aspx, paragraph "Preparing your Development Computer".

    Am I doing something wrong in deploying the OutlookViewCtl control to the end users? Is there an extra step I'm missing?

    Thank you in advance,

    Jason


    Jason Orphanidis

    Tuesday, March 20, 2012 2:49 PM

Answers

  • OK problem solved:

    After installing ProcessMonitor from sysinternals and intercepting the registry keys that failed to load(!), I found that the CLSID that was missing was {261B8CA9-3BAF-4BD0-B0C2-BF04286785C6}, of OVCtl.OVCtl program id.

    The test machine had {0006F063-0000-0000-C000-000000000046} under OVCtl.OVCtl, instead.

    A simple google search brought me to http://support.microsoft.com/kb/972363 which made me understand that an essencial security update had not been applied to the test machine...

    Why not? because my test machine is a virtual PC whose Windows have not been activated (don't want to waste valid serial numbers on dummy installations) and therefore denies receiving Windows updates!

    OMG!

    Anyway, case closed, thanks Damian and Ken for their input.


    Jason Orphanidis

    Friday, March 23, 2012 2:23 PM

All replies

  • Does it work correctly if you do register the view control manually using regsvr32? If so you will have to register the control as part of your deployment.

    --
    Ken Slovak
    MVP - Outlook
    http://www.slovaktech.com
    Author: Professional Programming Outlook 2007
     
     
    "Jason Orphanidis" <=?utf-8?B?SmFzb24gT3JwaGFuaWRpcw==?=> wrote in message news:de73a185-ed93-44b8-99e4-7ae972f4cad0...

    Hello everyone,

    I have developed an Outlook 2007 addon with Visual Studio 2008.

    For my deployment method I have chosen:

    1. Active Directory-assigned packages to all Windows 7 computers (I only deploy to Win7 machines) of

     - Office 2007 PIA
     - VSTO 3.0 Runtime

    2. ClickOnce installation of the addon itself, to benefit of

    - no admin rights required for the installation
    - built-in update mechanism for new versions of the addon

    My addon works perfectly except for one form that contains an OutlookViewCtl control.

    When the user tries to bring up the form, an exception is thrown "Class not registered".

    I assume that the class that is not registered is OutlookViewCtl 's class. After all, the form only contains two Windows.Forms.Radiobutton controls and the OutlookViewCtl.

    As I understand, the proper installation of OutlookViewCtl is the responsibility of Office 2007 PIA.

    The installation package of Office 2007 PIA was constructed by me following the exact instructions of http://msdn.microsoft.com/en-us/library/cc563937(office.12).aspx, paragraph "Preparing your Development Computer".

    Am I doing something wrong in deploying the OutlookViewCtl control to the end users? Is there an extra step I'm missing?

    Thank you in advance,

    Jason


    Jason Orphanidis


    Ken Slovak MVP - Outlook
    Tuesday, March 20, 2012 3:14 PM
  • No it doesn't.

    The two relevant assemblies

    AxInterop.Microsoft.Office.Interop.OutlookViewCtl.dll
    Interop.Microsoft.Office.Interop.OutlookViewCtl.dll

    are in the GAC and it would be very difficult to get a file path to register them anyway.
    But even when I manually registered them, the problem still remains.


    Jason Orphanidis

    Wednesday, March 21, 2012 7:43 AM

  • --
    Ken Slovak
    MVP - Outlook
    http://www.slovaktech.com
    Author: Professional Programming Outlook 2007
     
     
    "Jason Orphanidis" <=?utf-8?B?SmFzb24gT3JwaGFuaWRpcw==?=> wrote in message news:689ed1ae-bb40-4682-a78f-ed583fcb2e7a...

    No it doesn't.

    The two relevant assemblies

    AxInterop.Microsoft.Office.Interop.OutlookViewCtl.dll
    Interop.Microsoft.Office.Interop.OutlookViewCtl.dll

    are in the GAC and it would be very difficult to get a file path to register them anyway.
    But even when I manually registered them, the problem still remains.


    Jason Orphanidis


    Ken Slovak MVP - Outlook
    Wednesday, March 21, 2012 1:26 PM
  • Sorry no it doesn't.

    The way I'm showing the OutlookViewCtl isn't via a web page, but via Windows.Forms.

    That is, I have added a menu item in the outlook menu and when the user selects it I just do this:

                    if (frm == null)
                        frm = new SearchFrm();
    
                    frm.Show();
    


    Jason Orphanidis

    Thursday, March 22, 2012 8:55 AM
  • Found something new:

    My development machine is x64. The OutlookViewCtl form shows without error in x64 machines, but fails in x86 machines.

    Maybe it has something to do with the fact that I compile/build/publish from a 64-bit machine?


    Jason Orphanidis

    Thursday, March 22, 2012 2:05 PM
  • That could definitely make a difference, yes.
     
    What bitness is the Outlook you're using and that you're testing on?
     
    I'd actually assumed that the view control would be a 32-bit ActiveX control and wouldn't work at all in 64-bit Outlook, but I suppose for 64-bit systems it was compiled as 64-bit.

    --
    Ken Slovak
    MVP - Outlook
    http://www.slovaktech.com
    Author: Professional Programming Outlook 2007
     
     
    "Jason Orphanidis" <=?utf-8?B?SmFzb24gT3JwaGFuaWRpcw==?=> wrote in message news:876eae2d-186b-4f42-a7d6-a815163b61b8...

    Found something new:

    My development machine is x64. The OutlookViewCtl form shows without error in x64 machines, but fails in x86 machines.

    Maybe it has something to do with the fact that I compile/build/publish from a 64-bit machine?


    Jason Orphanidis


    Ken Slovak MVP - Outlook
    Thursday, March 22, 2012 3:44 PM
  • Development machine is 64 bit, but the office i'm using is 2007 and I think it only comes in 32 bit.

    I'm testing in Office 2007 (so always 32 bit), but the OS could be either 32 or 64 bit.


    Jason Orphanidis

    Thursday, March 22, 2012 4:17 PM
  • check your generated interop assembly for outlookviewctl that you deploy along with your add-in, for example using ILAsm or reflector - most probably it is not compiled as AnyCPU but rather as 64 bit assembly. If that is the case, you must generate interop assembly that is 'anyCPU'
    Thursday, March 22, 2012 9:13 PM
  • I only have ILAsm (MSIL Assembler) and dotPeek

    dotPeek doesn't show info on CPU option that was used when compilation took place.

    Could you provide some usage info for MSIL? From MSDN help I don't see how it could be of use. maybe you mean something else?

    Thanks


    Jason Orphanidis

    Friday, March 23, 2012 11:23 AM
  • sorry, my bad, in ildasm you cannot see this. Anyway, try using tlbimp to manually generate interop assembly and be sure to pass /machine:Anostic parameter to generate interop for anyCPU. Then reference this interop and bundle it with your add-in and test on target machine.
    Friday, March 23, 2012 11:54 AM
  • OK problem solved:

    After installing ProcessMonitor from sysinternals and intercepting the registry keys that failed to load(!), I found that the CLSID that was missing was {261B8CA9-3BAF-4BD0-B0C2-BF04286785C6}, of OVCtl.OVCtl program id.

    The test machine had {0006F063-0000-0000-C000-000000000046} under OVCtl.OVCtl, instead.

    A simple google search brought me to http://support.microsoft.com/kb/972363 which made me understand that an essencial security update had not been applied to the test machine...

    Why not? because my test machine is a virtual PC whose Windows have not been activated (don't want to waste valid serial numbers on dummy installations) and therefore denies receiving Windows updates!

    OMG!

    Anyway, case closed, thanks Damian and Ken for their input.


    Jason Orphanidis

    Friday, March 23, 2012 2:23 PM