Hir&#233&#59;n

Hi,

I have just implemented a solution based on the approach mentioned here: Outlook Customization for Integrating with Enterprise Applications. (i.e. VSTO SE based Outlook Add-in with custom Folders having their webviews / folderhomepages which in turn host managed .Net user-controls)

And it seems to work fine, except for a problem with the COM Registration of the user-control to be hosted on my Outlook Folder webview. Everything seems to work fine on the development machine.

I have observed the difference in the Registry Keys creation on my development machine and the target deployment machine. Especially the sub-keys under HKEY_CLASSES_ROOT\CLSID\<control GUID> are different/missing in the Target deployment machine.

Ex. the dev machine has the key hierarchy as follows:

HKEY_CLASSES_ROOT\CLSID\<control GUID>

- Implemented Categories (+subnodes)

- InprocServer32 (+subnodes)

- ProgId [1 (Default) key]

While the Target machine has only the Implemented Categories key under the HKEY_CLASSES_ROOT\CLSID\<control GUID> node

I must be going wrong with the installer Tongue Tied or something but am quite clueless.

Any pointers

Thanks



Re: Visual Studio Tools for Office using MAPIFolder.WebViewURL (CRMToday integration with Outlook) COM issue

Hirén

Another rookie-mistake. Pretty new at making Setup projects.

The issue was fixed. Basically, all our managed user-controls (to be hosted in Outlook) are clubbed under a common assembly. This assembly is included in the Outlook Addin setup as a dependency.

The step I managed to skip was to set the "Register" property of the common dll to "vsdraCOM" from the Dependencies folder.





Re: Visual Studio Tools for Office using MAPIFolder.WebViewURL (CRMToday integration with Outlook) COM issue

Ji Zhou C MSFT

Hi,

Have you set the Register property of Primary Output to be vsdrpCOM

And along with the article, there is an example available to download. I run that example in my side. The setup works fine in a client machine. To let setup file register the user control in deploying process, this example implement an installer class and use the project to be a custom action in setup project. I think comparing your codes with the example codes through should help you find where the error is.

And based on my opinion, this is not a VSTO related issue and out of this forums scope.

Thanks

Ji






Re: Visual Studio Tools for Office using MAPIFolder.WebViewURL (CRMToday integration with Outlook) COM issue

Ji Zhou C MSFT

Sorry about that I open this thread this morning and did not refresh it before replying.

Well, glad to hear that you fixed it!

Thanks

Ji






Re: Visual Studio Tools for Office using MAPIFolder.WebViewURL (CRMToday integration with Outlook) COM issue

Hirén

Hello,

Well, I did manage to fix that issue alright. But am now porting my Outlook 2007 addin setup for Windows Vista compliance. And of course, am facing a few issues.

For starters I have disabled the UAC on Vista, and this causes the existing setup to be installed alright. The add-in is loaded into Outlook fine, but again there is this similar problem when I try to access the managed user-control from the Outlook folder web view. This time around even the necessary registry key/values are created in the HKEY_CLASSES_ROOT. Am kinda clueless on this behaviour, must be something Vista specific - but am not sure.

Would appreciate any pointers.

-Hiren