Yes, you need to have the administrative permissions to register “secman.dll” or “secman64.dll”. Sorry, I don’t know any way to use registration free COM. You can try using Outlook Security Manager without registration, it’s a new feature introduced in the latest build of Security Manager 2010 (2010.6.1.3016) and it is still on the testing stage; but possibly, it will work for you.You can download the latest build from the Outlook Security Manager download page.

To deploy your project without registering Security Manager dlls, please execute the following steps:

1. Include the SecurityManager.2005.dll assembly in your setup package. This assembly should be placed into a folder where all your deployed assemblies are located.
2. Include two redistributable libraries – secman.dll and secman64.dll – put them either into the shared folder of Windows, “[Common Files Folder]\Outlook Security Manager” or into your application folder.
3. That’s all. You don’t need to register any dlls.

Like Ryan I want to deploy an add-in with both secman and secman64 but via an MSI. (A lot of my clients use proxy server which obstruct Click-Once). If I do it the way described in your very useful articles it all works fine but the resulting MSI fails if run ny a non admin user – there is a warning that secman has failed to register and although the setup completes the addin is not loaded by Outlook.

If I could find a way to use registration free COM for both secman and secman64 then an ordinary user could install the add-in

If you deploy an ADX-based add-in via ClickOnce with Add-in Express 2010 for Office and .net, you needn’t use ManifestFix.exe or register dlls manually.
If you have a SecurityManager.2005.dll reference in your project, then after selecting “Publish ADX Project” from the Build menu and clicking the Populate button in the “Publish” dialog window, you will see that the secman.dll and secman64.dll files were added automatically to the Files list for publishing. They will also get registered automatically when your add-in is installed on the end-user PC. It’s a feature of Add-in Express 2010 :)

if (System.Deployment.Application.ApplicationDeployment.IsNetworkDeployed && System.Deployment.Application.ApplicationDeployment.CurrentDeployment.IsFirstRun)

throw an error that “Application identity is not set”. I am deploying the addin via ClickOnce.

I am trying to follow the series of posts regarding using RegFree COM with Outlook Security Manager but getting lost along the way somewhere. I don’t suppose you have some complete list of steps somewhere or demo project I could download that covers how to do this for a ClickOnce deployed Outlook addin that needs to target Outlook 2010 32 and 64 bit?

Thanks

Yes, you are right, if you deploy a standalone application, you can still build for AnyCPU using the CorFlags Conversion Tool to configure the bitness flag depending on the Outlook bitness. If you do not use the CorFlags Conversion Tool, then you should build your application with “x64″ for Outlook 64-bit and with “x86″ for Outlook 32-bit.

But if you deploy an add-in (not a standalone application), you needn’t use CorFlags, you can always build your add-in for AnyCPU.

“In the ManifestFix.exe utility, I allowed for the second condition too – for Outlook 32-bit, your application must be compiled under an x86 platform, for Outlook 64-bit – under x64. I used the CorFlags Conversion Tool for this.”

Are you saying that we DO have to target the addin for a specific CPU or that you are flipping the bit using CorFlags (and we can still build for AnyCPU, is this right?)

Can you clarify this?

Thanks!