Installing Outlook Addin in different computers - c#-3.0

I created a outlook add-in using visual studio 2008 and now i want to install the add-in in different computers.
Problem-: After installing the add-in, the outlook does not shows any thing and if i visit trust center-> add-in-> it shows there and after enabling it, it got disable automatically.
Using outlook 2007, windows XP, .NET 3.5 .

Outlook disables its add-ins if they fail to load or crash Outlook.
To enable your add-in try to change the following values in registry:
HKCU\Software\Microsoft\Office\Outlook\Addins\<add-in
name>\LoadBehavior = 0x3
or
HKLM\Software\Microsoft\Office\Outlook\Addins\<add-in
name>\LoadBehavior = 0x3

Related

My Word office addin doesn't work?

I have created an office addin for Word 2010 targeting .net 4 and this should apparently work in office 2007.
I have created the installer per this article with the exception that I include a dll in the dependencies rather than in the bootstrapper for the prerequisites.
The installer installs the vsto and the registry keys in
HKCU\Software\Microsoft\Office\Excel\Addins\ProjectName
The pc also has .Net 4 and the Office 2007 Primary interop assemblies.
The addin doesn't appear in Word 2007, any ideas where I could be going wrong?
UPDATE:
You have to sign your addin, this was pretty obvious! Office now recognises the addin but its gets a runtime error that I can't debug. Tried to debug with these steps with no luck!
Had to build for correct CPU version of office, in my case 32bit, Any CPU didn't work!

Manage COM Add-ins dialog fails to make an installed Outlook add-in ACTIVE on target machine

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:
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 ??).
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.
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?

What are reasons for Outlook 2007 to not load CLR 4 with installed VSTO 2010 and a registered managed application level add-in targeting .net 4?

I have developed an application level add-in for Outlook targeting Outlook 2010 and .NET 4 and I want to run it on Outlook 2007, which should not be a problem due to the new "no pia" feature of .NET 4 (see this blog post).
However, after deploying the add-in with my Windows Installer package (the same package works for Outlook 2010), the add-in does not get loaded correctly and its load behavior is set to 2.
The test machine has the following software installed (in the given order):
Microsoft Windows XP with Service Pack 2 (x86)
Microsoft Office 2007 Enterprise
Windows Installer 3.1
Microsoft Windows XP Service Pack 3 (x86)
Microsoft .NET Framework 4.0 (Extended)
Microsoft Visual Studio 2010 Tools for Office Runtime (x86)
The utility assemblies are included in my deployment location and the add-in is registered correctly (shows up in Outlook trust center and deployment manifest is also included). I do not reference any third party libraries.
The strange thing is that the CLR 4 is not even loaded into Outlook, which I can see through the Visual Studio 2010 Remote Debugger. When I create an test add-in on my development machine and throw an exception on add-in startup, the load behavior also gets set to 2 on startup (without debugging), but at least the CLR 4 gets loaded into the Outlook process. Has anyone ideas what (probably missing dependency) could cause the VSTO 2010 Runtime to not load .NET Framework 4? I have also tried reinstalling VSTO which caused no effect.
Best Regards,
Oliver Hanappi
I found the solution on the msdn forums. There is a problem when no clr 2 is installed. A hotfix is required in this case. For more details see http://social.msdn.microsoft.com/Forums/en/vsto/thread/d95cc828-fdb9-4622-bf09-291a25cea81b.

Using Wix to Deploy an Outlook Add-In

I have a requirement to create an installer for an Outlook 2003 add-in that was created with VSTO.
We currently are using Wix for our installers as they play nice with MSBuild and I need to use it to create the installer for the outlook add-in.
I have no experience with outlook add-ins and am unsure exactly what is involved and how to go about creating the installer.
Can anyone share any experience/tips/examples that would help me please?
Thanks in advance,
B
I found this Microsoft article on VSTO add-ins deployment to be an absolute life-saver; I don't know about Wix, though. http://msdn.microsoft.com/en-us/library/bb332052.aspx
I've not done this in WiX but I have done it in InstallShield. Below with my notes from that time:
http://blog.deploymentengineering.com/search?q=vsto
One problem you will have is that WiX doesn't have a bootstrapper so you will have to find a way to chain the .NET Framework and VSTO redist ( also possibly the Office 2003 PIAs; you didn't say which version of VSTO you are using ) with your installer unless you choose to take the route that merely gates the install if those aren't found.
I recall using a DTF custom action to publish a certificate but I can't recall if that was needed for Office 2003 or only for Office 2007.

Visual Studio 2010 RC with Office 2010 and Office 2007 installed

I have Visual Studio 2010 installed on my Windows XP development machine along with Office 2007 Professional and Office 2010 Professional. I am trying to develop several add-ins for Office 2007; however, I prefer to use Office 2010 on a day-to-day basis.
How do I set Visual Studio 2010 to install the add-in and open Word 2007 when I press debug? Currently, Word 2010 opens, but does not recognize the add-in. Unless I have to, I would like to keep Office 2010 installed.
I don't know the specific answer to your question, but I am running Office 2010 and still working on Office 2007 add-in development.
My solution to this problem has been virtual machines. I don't do any development work on my laptop's primary OS. I don't even have Visual Studio installed there, but I am running Office 2010 and really like it so far.
For development I've got dozens of different VMs with various configurations of OS and Office version and other 3rd party software that I need to integrate with. I'm currently using Windows 7 and the new version of Windows Virtual PC, but I started this practice when I was using Windows XP and Virtual PC 2007.
One benefit of this is that if something goes wrong on one of my VMs, it doesn't bring down my whole machine.
I also don't start from scratch each time I need a new VM. I've got base images with only the OS installed, as well as OS + Office and OS + Office + Visual Studio, but nothing else. That way, whenever I need a new VM, I just make a copy of the base image that's closest to what I need and go from there. The only limitation is that the base images can't be joined to a domain, but that's not a big deal for me.
I would encourage you to try this yourself. It works great.