0
votes

My add-in targets Outlook 2007 and was built using C# with Visual Studio 2010. I have run into problems deploying this to different target machines by means of the SETUP.exe and "manifest" built by the Publish Wizard of Visual Studio.

My latest attempt to get this deployed to a target PC (i.e. one typical of other users where this will be deployed and lacking my development environment) gives strange problems:

  • the add-in installs OK (i.e. Setup had no complaints; program appears properly in Control Panel)
  • visiting Tools -> Trust Center -> Add-ins shows that my just-installed add-in is Inactive
  • clicking Go.. for the Manage COM Add-ins dialog & checking the box for mine then the Add.. button fails
  • a window looking like a browse dialog box titled "Add Add-in" comes up with "No items match your search" in the right-hand pane; at the bottom of this window is an empty textbox labeled "File name:" and a choice of "Executable Files" or "All files" for a file type. The add-in remains "inactive".
  • It is not clear to me what this dialog needs at this point to make it "active" (Load at Startup was part of the choices here).

NOTE:

  1. The 2 projects in this solution were compiled for a "target framework" of .Net 3.5 resulting in references to DLLs such as Microsoft.Office.Tools.Outlook.V9.0 and his companions (I guess that is "VSTO 3.0 ??).
  2. This solution launches Outlook properly on the development PC and the add-in is loaded successfully and runs as expected (against Outlook 2007 and/or Outlook 2010); so this seems related to deployement only.

Could there be a bug in the stuff built by the Setup wizard that comes with Visual Studio 2010? I read somewhere that the "manifest" can be "corrupt".

EDIT-UPDATE 3/31/2011:

I think I found the answer. I believe by using the "Publish Wizard" in VStudio which produces a SETUP.EXE, I was trying what is called "ClickOnce" deployment. Secondly, this addin for Outlook is NOT a "document level" addin but instead a "machine level" addin. Given these discoveries of better terminology, I found this at http://msdn.microsoft.com/en-us/vsto/ff937654.aspx:

"You can use ClickOnce to create and install self-updating applications with minimal user interaction. This has an automated mechanism for easily distributing updates to your application. However, ClickOnce is not capable of deploying components that require administrative privilege such as machine level add-ins. For solutions that require administrative privilege you can use Windows Installer to deploy a Visual Studio Tools for Office customization."

So, I will try to make a Windows Installer. Any confirmation would be appreciated.

1

1 Answers

0
votes

I am confident the ClickOnce style of deployment will NOT work for my machine level add-in for Outlook 2007. Therefore, I am answering my own question by stating only that this requires a Windows installer (and setup) that can built with the properly chosen Visual Studio template.

The sad news is that in my testing of said installer .msi and associated setup.exe for the pre-requisites the install to my target machine went well but when I test the operation of the addin itself inside Outlook I get a terrible APPCRASH event in Outlook.exe:

Problem signature:
Problem Event Name: APPCRASH
Application Name:   OUTLOOK.EXE
Application Version:    12.0.6550.5003
Application Timestamp:  4d10fbc4
Fault Module Name:  kernel32.dll
Fault Module Version:   6.0.6001.18215
Fault Module Timestamp: 49953395
Exception Code: e0434352
Exception Offset:   000442eb
OS Version: 6.0.6001.2.1.0.256.1
Locale ID:  1033

Additional information about the problem:
LCID:     1033
Brand:    Office12Crash
skulcid:  1033

So the answer is that ClickOnce is not appropriate. The .msi appears to properly install the add-in but at runtime it blows sky high. Remember the addin works properly at runtime when launched via Visual Studio. Why does deployment have to be so damned difficult?