none
Preview msg files in .NET app using preview handler RRS feed

  • Question

  • I want to preview outlook files(*.msg) in my own .NET 4.0 program. And I have the same problem as described in the following article: How to preview msg files using preview handler : Currently my preview handler only works as long as my application matches the 'bitness' of Outlook i.e. if Outlook is 32 bit then my application needs to be 32 bit too, if Outlook is 64 bit then my application needs to be 64 bit. However, since my application is a multi-user application which runs directly from a network share and users have any working combination of 32/64 bit Windows and 32/64 bit Outlook I'd like to compile as 'Any CPU' to support all scenarios.

    On my test machine I have 32 bit Office installed on Win7 64 bit. Surprisingly I can preview Word, Excel and PDF files in my 64 bit application. It's just Outlook that won't work. However, Windows Explorer doesn't have a problem displaying *.msg files in its own preview. I noticed two prevhost.exe processes when Windows Explorer displays previews (one 32 bit, one 64 bit). What's the trick here?

    Thanks for any ideas,
    Guido

    Saturday, May 5, 2012 3:13 AM

Answers

  • So far I couldn't find any useful information about prevhost.exe Maybe I'll try to implement my own out of process host and mimic the Windows Explorer behavior. Thanks for your ideas!

    Monday, May 7, 2012 8:26 AM

All replies

  • i would guess that problem is with your interop assemblies for preview handlers - turn off embedding of interop types so you will get separate interop assembly and recompile your app. then go to output dir and look using reflector what is the bitness of interop assembly - it should be anycpu
    Sunday, May 6, 2012 7:18 AM
  • As far as I know I don't embed interop types. I'm using a sample from the 'Coding4fun Developer Kit'. See PreviewHandlerHostControl.cs

    My assembly that declares the necessary COM interfaces compiles as 'Any CPU'.

    Sunday, May 6, 2012 8:15 AM
  • ok, show us screenshot of registry entry (and its subkeys) that you use to instantiate msg preview handler
    Sunday, May 6, 2012 10:22 AM
  • First I search the registry for the file extension. In case of Outlook mail it's '.msg' and the subkey ShellEx\{8895b1c6-b41f-4c1c-a562-0d564250836f} contains the CLSID for the preview handler:

    [HKEY_CLASSES_ROOT\.msg\ShellEx\{8895b1c6-b41f-4c1c-a562-0d564250836f}]
    @="{435fdba0-964c-43a7-8aff-cc94e21b2249}"

    I use this CLSID {435fdba0-964c-43a7-8aff-cc94e21b2249} to create an instance of the preview handler.

    However, just for testing purposes I also tried several other of the registered preview handlers that relate to mail:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\PreviewHandlers]
    "{b9815375-5d7f-4ce2-9245-c9d4da436930}"="Microsoft Windows Mail Mime Preview Handler"
    "{f8b8412b-dea3-4130-b36c-5e8be73106ac}"="Microsoft Windows Mail Html Preview Handler"
    "{92dbad9f-5025-49b0-9078-2d78f935e341}"="Microsoft Windows Mail Mime Preview Handler"
    "{BFD468D2-D0A0-4bdc-878C-E69C2F5B435D}"="Microsoft Windows Mail Html Preview Handler"
    "{53BEDF0B-4E5B-4183-8DC9-B844344FA104}"="Microsoft Windows MAPI Preview Handler"
    "{435fdba0-964c-43a7-8aff-cc94e21b2249}"="Microsoft Office Outlook MAPI Preview Handler"

    Unfortunately without success. The only thing I get is an error message:
    "Either there is no default mail client or the current mail client cannot fulfill the messaging request. Please run Microsoft Outlook and set it as the default mail client"

    Sunday, May 6, 2012 5:25 PM
  • ok but i was more interested in values of subkeys in HCR\CLSID\guid\ where values for thread apartment and local server bitness are stated. i will check this myself on tuesday. in the meantime going back to your original idea of workaround - create 32-bit main exe which will read on start value from registry about installed office bitness (for 2010 it will be there, otherwise you can assume this is 32-bit). If bitness of office matches your app - go ahead, otherwise launch from your exe 64-bit one that lies in the same folder or subfolder and close your current (32 bit) one. Is such workaround sufficient for you?
    Sunday, May 6, 2012 6:25 PM
  • Windows Registry Editor Version 5.00

    [HKEY_CLASSES_ROOT\CLSID\{435fdba0-964c-43a7-8aff-cc94e21b2249}]
    @="Outlook MAPI Mail Previewer"
    "AppID"="{e49dde22-c999-4d57-86fe-6d6c610d4b94}"
    "DisableLowILProcessIsolation"=dword:00000001
    "DisplayName"="@C:\\Program Files\\Microsoft Office\\Office14\\MAPISHELL.DLL,-127"
    "Icon"="@C:\\Program Files\\Microsoft Office\\Office14\\MAPISHELL.DLL,-504"

    [HKEY_CLASSES_ROOT\CLSID\{435fdba0-964c-43a7-8aff-cc94e21b2249}\InProcServer32]
    @="C:\\Program Files\\Microsoft Office\\Office14\\MAPISHELL.DLL"
    "ThreadingModel"="Apartment"

    --

    I feel a little unhappy when Outlook dictates the bitness of my application. How does Windows Explorer do the trick? Can I somehow use prevhost.exe, too?

    Sunday, May 6, 2012 7:07 PM
  • i guess explorer is doing it out of main process, so it spawns child process with proper bitness, this is almost the same what i suggested above. Move all logic to shared dll and make main exe files (which dictate bitness of process) as lightweight as possible. Of course you can try to dig out some info about prevhost, maybe it is not so scary, but in worst case scenario you will have to open direct support incident to get info you need.
    Sunday, May 6, 2012 7:39 PM
  • So far I couldn't find any useful information about prevhost.exe Maybe I'll try to implement my own out of process host and mimic the Windows Explorer behavior. Thanks for your ideas!

    Monday, May 7, 2012 8:26 AM