I have an outlook plugin built with Visual Studio 2010 (.net 4.0 Client Profile), that works fine in Outlook 2007 and Outlook 2010. I just tested on 2013 and even installing the addin seems to crash. After googling, I see a few examples of issues people have faced but fundamentally can't get a straight answer to this question:
Is there any prerequisite that would not allow a VS 2010 Outlook addin to just work on 2013 or do I need to upgrade Visual Studio and Create an Outlook 2013 specific version of my addin?
The Running Solutions in Different Versions of Microsoft Office article describes all details. It states the following:
If you developed solutions for Office 2010, you can run the same solutions in Microsoft Office 2013. Solutions that were created by using Visual Studio 2013, Visual Studio 2012 or Visual Studio 2010 can run in Office 2013, Office 2010, or the 2007 Microsoft Office system.
What is the target .Net framework of your add-in? Did you try to debug the code? Do you get any exceptions?
Do you have Outlook 2013 on the machine you have the add-in project on? If you do, you can debug from VS 2010 by setting the "Start external program" in the Debug tab of the project properties window to the Outlook 2013 .exe. When I created my add-in I was able to debug it using whatever version of Outlook was on my development computer and I don't remember changing anything other than the external program path.
If you are using setup project for the installation it needs a different ComponenedId when you create its launch conditions. You'll need two different setup projects to install on Outlook 2010 and 2013. Here are the Office 2013 PIA keys and Office 2010 keys.
Did you try enabling the add-in again? It won't run after its in the disabled queue. After you re-enable it from the disabled add-in screen, you can then check the box in the COM-AddIn screen to have it load which then should prompt you more detail since you set the VSTO_SUPPRESSDISPLAYALERTS variable about what may have happened in the first place.
The problem can be that the add-in had been hard disabled by Outlook. Notice that the add-in did not show up under Inactive Application Add-Ins, but rather under Disabled Application Add-Ins. That makes a difference: In the latter case, just going to the COM-AddIn screen and ticking the check box is not enough to solve the problem.
Follow these steps for hard disabled add-in?
Goto the Manage box, change COM Add-ins to Disabled Add-ins, and then
click Go. Select the add-in and click Enable. Click Close. OK, now
the add-in can be loaded again:
In the Manage box, change Disabled Add-ins to COM Add-ins, and then
click Go. select the check box next to the disabled add-in. Click
OK.
Reference THIS site for further details.
I vaguely remember encountering an AddIn crashing on installation in the past... resolution is:
Install Visual Studio 2010 Tools for Office Runtime on the target machine.
Try the VSTO AddIn install again and you wont get the crash during installation.
Before trying to install it, you can try to run it trought the debugger to have more info on the real problem. As far as I remember, you just need to go to your project properties and change the launched version of outlook while debugging...
You can follow this link for more info : http://www.greycastle.se/vsto-project-office-target-version/
Assembly Loading issues are difficult to debug because there are at least two layers to this when dealing with Managed and Native code.
When an executable is started the native loader must find the file, load it into memory along with all the dependent DLLs to make it run.
The native loader looks into the assembly manifest to determine this information and then simply hunts down all the DLLs and load them into memory (in order).
You can easily see this process using WINDBG and pointing to an EXE and running it from Windbg. The list of modules being loaded is the native loader at work.
If a dependency is a .NET managed code assembly then the native loader transfers the loading request directly to the managed loader, known as "Fusion".
You can easily set up the FusionLOG viewer to see what is happening http://msdn.microsoft.com/en-us/library/vstudio/e74a18c4%28v=vs.100%29.aspx
Failures of loading at either the managed layer or within the managed layer are easily spotted either through WINDBG for Native or the Fusion Log View for Managed code.
A few hints on Managed DLL loading: If an assembly holds a reference to a dll that is not included in that assembly, there is a strict order of "probing" which is followed to find the dll. There will be a minimum of three attempts to find the DLLs in different places such as in the assembly, in the program root path and in the GAC. If the three attempts fail, loading is stopped at that point and the program will not run. When this happens it is often considered a system level environmental issue; however, in reality it's a programming issue because unless pre-requisites are fully know by the system administrator there is no way they can guess at this stuff. If you are a programmer who is including other dependent dlls you should always consider whether or not to place them into the assembly to stop this problem. Otherwise you, the system admins, and folks using your program will have to wait until the root cause is determined which takes a long time.
You may say, well I was told by another department to use this dll and I have no idea what the other dependencies are! This is no excuse, as there are excellent tools such as ILDASM and even managed code Dependency walkers that will tell you everything that's needed. The best way to package these "other" dlls is to simply include them in your assembly.
Related
I am coding an Outlook add-in using VSTO on Visual Studio 2019 (targeting Outlook 365). I want to do a test deployment install, rather than running it through Debug mode using Visual Studio. I figured that the "first step" for that would be to run the add-in using "Release" mode in Visual Studio. However, the add-in will not load in Outlook when I run it that way in Visual Studio.
When I first attempted this, a pop-up window appeared warning me that I am not running in Debug mode, and gave me a few options, such as "Stop Debugging" and something like "Run Just My Code" and 2-3 other options. I selected the first option "Stop Debugging", and Outlook started but did not load the add-in. Clicking into the Options on Outlook showed that it disabled the add-in because "it caused Outlook to crash." I have not been able to get that initial pop-up window to appear again, despite cleaning both the release and debug versions, and confirming those were removed from the project folders.
I can still run the add-in in Debug mode fine.
I found this answer from Eugene Astafiev regarding "hard" and "soft" disabling of add-ins by Outlook, and followed the instructions he linked-there -- but the add-in still refuses to load from Release mode. I also checked the various registry entries listed in the responses to this question and my add-in is actually listed under a "Never Disable" registry entry for Outlook.
Should I have selected a different option on that initial pop-up that appeared when I first tried to run the add-in in Release mode? And if so -- how do I get that pop-up to appear again?
Do I need to manually add entries to the registry when running in Release mode, to get Outlook to load the add-in? That seems counterintuitive given that Visual Studio automatically does that when running in Debug mode.
I still have not gone through the process of creating an installer per the MS instructions here, thinking that I need to get the add-in working in Release mode on Visual Studio first.
But is that actually the case? Can I create the installer using the Debug mode version? The MS installer instructions referenced above makes no mention of having to use the "Release" version, and this video (starting at 12:15) on deploying an Excel add-in using Visual Studio appears to just use the "Debug" version.
But by deploying from the Debug version, will it still be "optimized" for performance with the "debug symbols" removed, etc. as discussed in this video (starting at 5:06)?
And then that begs the final question -- should we even bother with "Release" mode on Visual Studio when coding an Outlook VSTO add-in?
I've searched and searched and have been unable to find any documentation discussing VSTO add-ins and "debug" mode versus "release" mode in Visual Studio, so any help or reference to such documentation would be greatly appreciated. Thanks in advance.
UPDATE: I tried creating a stand alone installer from Debug mode -- did not work. Creating the setup project in Visual Studio also killed my add-in from getting loaded by Outlook even in Debug mode. Got an "unhandled exception" popup in Outlook -- despite no exceptions coming up in Visual Studio. To be safe -- I had backed up the entire solution prior to trying any of this (learned that lesson the hard way about 10 years ago). Restored that -- at first it wouldn't load, but then remembered to clean the solution which did the trick.
UPDATE: Okay, making some progress. I had a "eureka" moment, when it dawned on me that starting Outlook by pressing "Start" in Visual Studio may be causing the problems under "Release" mode, since Visual Studio's debugger might still be trying to hook into the add-in while it is running. Instead -- I made sure to "clean" out the Debug version, switch to Release mode, and then I just built the solution without hitting Start.
At first the Add-In still wasn't loading, but this time because it "slowed down" Outlook, rather than crash it. I finally got it to load after I deleted the "Outlook\Resiliency\DisabledItems" keys from the registry as per this answer, and then launched Outlook directly rather than via the Start button in Visual Studio.
Now I'm going to try to create the Installer again, but this time using the Release version. I've been paying close attention to the files and registry keys that are created and deleted by Visual Studio for the "Debug" and "Release" versions, and think I have a better grasp on what the installer needs to do.
After several days and many hours of research and experimenting, I finally have my add-in installing, loading and running as-expected in Outlook on a test machine. To perhaps help anyone else struggling with these questions in the future, here is essentially a "brain dump" of what I learned:
The "Start" Button in "Debug" versus "Release" mode
As I mentioned in the second "Update" to my question, I had a "eureka" moment when I realized that running the add-in by hitting the "Start" button in Visual Studio is very different from doing so by launching Outlook directly outside of Visual Studio. As I discuss at the end of this post, I am fairly new to the Visual Studio IDE, and I had never seen this distinction discussed in documentation or forum postings.
Importantly, hitting the Start button inside of Visual Studio in "Release" mode triggers the following pop-up dialog window (at least initially -- see below):
As I discuss in my question, the first time I saw this, I clicked "Stop Debugging" and my add-in would not load in Outlook, in either Release or Debug mode. I was able to get this pop-up to reappear only after rolling back to a backup copy of my solution from before creating the Setup project. I discovered that accidentally by inadvertently clicking "Start" while in "Release" mode, rather than launching Outlook directly.
This time I clicked "Disable Just My Code and Continue" -- and my add-in loaded up fine inside of Outlook. Although I suspect that if I were trying to debug with breakpoints -- those likely would not have worked.
Also, the pop-up now still reappears when I hit Start in Release mode. I was never able to figure out why it permanently disappeared after I had hit "Stop Debugging" that first time. Maybe I had accidentally hit the last option with "(Don't Ask Again)" -- but I swear that I had hit the first option.
As for "Just My Code", here is a good SO question and answer discussing what that means.
"Optimized" Code and "Release Bugs" in Release Mode
Although I was able to get my add-in to load in Outlook in Release mode, it was exhibiting some strange behavior. After reading this SO question and several of the answers, especially this one, it dawned on me that this was being caused by one or more "release bugs" as a result of the optimization Visual Studio was doing to my code.
I decided that rather than spend countless hours trying to debug the IL ("intermediate language") code generated by Visual Studio -- I would instead see if I can just deploy the Debug version of the solution, which as I discuss below, I was able to do just fine.
Although there are clearly (and hotly debated) pros and cons to deploying a "Debug" version of an add-in (see the above SO link), such as maybe a performance/speed hit -- for me the choice was clear, given that the Debug version runs completely as expected without the weird behavior exhibited by the Release version.
The Registry and "Debug" versus "Release" mode
I also knew that for VSTO add-ins, in addition to writing/deleting files to "bin/Debug" and "bin/Release", Visual Studio also writes/deletes entries to the registry. When Outlook starts, that is where it checks to see if any add-ins should be loaded, as described by MS here.
However, I was not familiar with exactly how this works. I used the info provided by Microsoft at the link above to search the registry on my development machine to find the subkeys and values actually generated and deleted by Visual Studio each time I did a "build" and a "clean."
This was not as simple as looking in the "HKEY_LOCAL_MACHINE" and "HKEY_CURRENT_USER" sections (or "hives") of the registry. When I did that, my add-in was not under "SOFTWARE\Microsoft\Office\Outlook\Addins" in either hive. After doing a "find" for "Addins" -- and hitting F3 repeatedly -- after about 20 minutes or so I finally found it. (In hindsight -- I should have searched for the name of the add-in, oh well.)
For whatever reason, Visual Studio was instead saving the keys to my specific "HKEY_USERS" hive of my registry -- where there were 9 subdirectories based on various accounts I had setup on my development PC over the years. The hive for my currently active account was labeled with a long cryptic numeric string:
Finding this was crucial to my understanding, because then I could "build" and "clean" the solution in both Debug and Release mode, and see the changes Visual Studio was making to the registry each time.
Every VSTO add-in must have a subkey in the proper Outlook/Addins hive, and must have all four of the values shown in the image above ("Description", "FriendlyName", "LoadBehavior", and "Manifest").
The "Manifest" value is the one that tells Outlook where to find (somewhat confusingly) the "add-in.vsto" file (not the "add-in.manifest" file). It must begin with "file:///" and end with "|vstolocal".
Because my add-in uses a FormRegion, the FormRegions subkey was also important to track and learn how to use properly. The FormRegions subkey must contain a subkey for each type of Outlook item that your FormRegion is used for. In my case, it is only used for a MailItem, which in the registry is called (somewhat confusingly) "IPM.Note". The format for the value in that subkey is:
Name: [Add-in name].[FormRegionName]
Type: string (REG_SZ)
Data: =[Add-in Subkey name under Addins]
For example, if your add-in is named "TestOutlookAddin" with a FormRegion called "FormRegion1", and the main add-in subkey is named "TestCompany.TestOutlookAddin", then this subkey should look like this:
MS Setup Instructions Did Not Work for my add-in
I obtained all of the above info pretty much as a result of my frustration using the instructions provided by Microsoft for creating a VSTO add-in installer, with my add-in repeatedly failing to load on my test machine. It was failing whether I tried "Click Once" or the standalone Windows Installer method.
As for Click Once, after reading this Code Magazine article, I determined that that method was not appropriate for my add-in, especially because there are configuration settings the user can set, and a local SQLite database saved on the user's machine.
As for the stand alone installer method, when I couldn't get that to work with my add-in, I experimented with creating a very simple add-in with no third-party libraries -- and I was able to get the add-in installed and working using the above instructions from Microsoft. But I simply could not get my full add-in to load and run using that method.
I believe this is (partially) due to the fact that my add-in uses several third-party Nuget packages, and two class libraries that I coded myself.
On a whim -- assuming that it wouldn't work -- I tried simply copying the entire "bin/Release" folder to my test machine, and then manually created the appropriate keys in the registry (as I discussed above). It worked.
It worked, despite not having Visual Studio installed on that machine, the add-in loaded and ran when I started Outlook. However, the add-in was exhibiting the strange "release bug" behavior I discussed above.
So I tried again, this time copying over the "bin/Debug" folder instead. It worked.
It loaded and ran on my test machine exactly as it did on my development machine.
So I learned (the hard way) -- that deploying a VSTO add-in (or at least MY add-in) requires essentially two steps:
Copy all of the files from either bin/Debug or bin/Release to the target machine.
Create the appropriate keys and values in the registry pointing Outlook to where those files are located.
And oh... I should add to that a "Step Zero":
Check for and install the .Net Framework and VSTO Runtime
Manual Copying versus Windows Installer -- Likely Security/Trust Problem
With the above in mind, I went back and created a Setup project in Visual Studio that simply copied all of the files from bin/Debug to the target machine and sets up the registry keys.
I did the install, but on launching Outlook, my add-in initially loads, and then mysteriously unloads silently.
I believe -- although have not 100% confirmed -- this is due to the way the security/trust settings are handled by Outlook when the add-in is "manually" copied to the machine versus being installed via a Windows Installer.
With the Windows Installer, I get the standard "UAC" type of warning message:
However, "manually" copying the files to the test machine and manually setting the registry keys, triggers instead the following "Microsoft Office Customization Installer" message upon starting Outlook:
Clicking the "Install" button results in the add-in loading and running properly.
I believe what is happening -- although it is a guess really -- is that the Windows Installer is not properly designating the security/trust settings on all of the .dll files used by my add-in, causing Outlook to disable it silently after starting to load it. There may be a way to configure the Setup project in Visual Studio to fix this -- short of going through the whole process of making the entire solution "trusted" with a certificate, etc. However, I have been unable to find any documentation on that.
Regardless, "manually" copying over the files and setting the registry keys triggers the "Microsoft Office Customization Installer" message, which then seems to properly configure all the trust settings to allow the add-in to install and load. Also -- that message appears only the first time Outlook is started with a new "manually installed" add-in.
Inno Setup To the Rescue
I did some more research and found the excellent free and open-source Inno Setup installer builder for Windows. This allowed me to create my own Installer that simply compresses the files in my bin/Debug folder into a single .exe file. Running that .exe on the target machine simply copies the files to the designated location on the target machine, and then writes the needed keys and values to the registry. Launching Outlook then brings up the above MS Office "Customization Installer" message, and clicking "Install" loads and runs the add-in which then runs perfectly fine.
What's great about this is that it is free, and provides the same "Installer" and "Uninstaller" type of functionality as the VS Setup project is supposed to. And there are scripts people have developed and shared for checking whether .Net is installed, etc.
Most importantly, it just works.
Final Note
Although all this was difficult to figure out on my own, it forced me to learn a great deal about the differences between "Debug" and "Release" builds in Visual Studio and VSTO, and for that I am grateful. I recently returned to coding after a 12 year hiatus, and this is my first attempt at an Outlook VSTO com add-in; and I had had only cursory prior experience with the Visual Studio IDE.
The Stack Overflow community and knowledge base has been a tremendous help to me, and I hope this Answer is a worthy addition to that. Although Microsoft appears to be moving away from VSTO com add-ins in favor of web-based add-ins -- there is still a place for com add-ins, particularly for accessing the user's local storage, which web-based add-ins cannot do (as far as I can tell). So -- although perhaps unlikely -- maybe this Answer will help someone in the future who is also struggling with "Debug" versus "Release" mode and how to deploy their VSTO com add-in.
I have developed one add-in using Outlook 2010 AddIn for outlook 2013 with visual studio 2012. I have developed User Controls and worked with Custom Task Pane in Add In.
It works perfectly when I debug add-in from visual studio. I have created setup file using Install Shield Limited Edition (following basic steps given by forum). However, if I install that add-in and open Outlook, Add In does not load and is not visible on Home tab. Nothing happen.
I haven't made any registry entry while building setup file.
Please let me know how can i make it working.
Thanks.
You will have to make an entry to Registry. You can simply do through Install shield program.
Here is the quick screen shot:
Make sure that the loadBehaviour is set to 3.
If there is any error in the addon on load then it will set to back to 0.
It has been long time I did not developed the addon but I am sure my information is correct.
Also make sure that the you look after for 64 vs 32 bits entry.
I found a quick link for you too: http://blogs.msdn.com/b/emeamsgdev/archive/2013/11/21/outlook-deploying-an-outlook-2013-add-in-using-installshield-le.aspx
I use Visual Studio 2010, C#, .Net 4.0.
I know how to create Excel Add-Ins that work pretty fine. But I'm a bit confused what the VS2010 is actually doing while debugging the add-in projects.
It seems that VS2010 uses a special format of "calling" the Excel when VS2010 calls the Excel in the debug mode. Then Excel looks into Bin directory of the Add-In project, looks through all the files (the generated .dll, .vsto file, maybe .manifest or some other files), loads the Add-In and sends back to VS2010 some notifications when something wrong happens.
As you can see, I have no idea how it actually works. So the question is whether you can anyhow direct me how to find any descent documentation describing this process of debugging the Excel Add-Ins.
I would really appreciate any comments where to start from. Thanks a lot!
VS installs your add-on as a normal Excel add-on when you start a debug session. It then launches Excel, and attaches itself as a debugger to Excel.exe. The VS debugger is quite capable of differentiating native code from .NET code.
It's been quite a while ago since I last wrote an Office add-on, but if memory serves, VS 2010 does not clean up after itself. It does not remove the add-on from Excel when the debug session terminates. You may have to do that manually. There may or may not be a context-menu item at the project node in in the solution explorer pane in VS that might uninstall it.
Just to be clear: Excel doesn't know about your debug session. Debugging is solely the purview of the VS debugger and the Win32 debugger APIs.
Debugging your add-in should be very straight-forward and should not contravene the established VS debugging experience. If you have some specific question regarding the process I would recommend asking that.
Visual studio team system 2008 keeps crashing on me. Sometimes it just freezes, or certain parts of the UI get messed up or a weird popup box saying something about unable to load parameters or saying something else about memory or any other number of things.
it usually happens when I do a "complex" task like go into debug mode or do a search across of whole solution or run a unit tests or something like that.
I rebooted my machine countless time, reinstalled it VS, changed my virtual memory settings, flush my page file on every reboot and anything else i could think of.
It seems like VS runs out memory or something.
I have a powerfully machine with lots of RAM so that's not the issue
any suggestions?
You can always try some standard Visual Studio troubleshooting steps:
Clean the solution
Delete / rename all files in your solution created by VS, i.e. all .ncb, .suo, .user files
Launch Visual Studio with all add-ins disabled: devenv.exe /SafeMode
Reset All Settings: Tools -> Import / Export Settings -> Reset All Settings
Delete HKCU:\Software\Micosoft\VisualStudio\9.0 and then restart Visual Studio
Repair the Visual Studio installation through Add/Remove Programs
You might also check whether there is a hotfix available addressing your issue (e.g. KB960075 sounds like a good candidate for you), or whether you find your problem already reported on the Connect website.
The first step is to uninstall all 3rd party add-ins on Visual Studio. In particular if you have multiple add-ins as they can interfere with each other in unexpected ways and cause crashes. After uninstalling repeat your scenarios and see if this fixes the issue.
If not then it's best to consult the application log and find out why Visual Studio is crashing. The log will contain at least the error code of the crash which can searched on google or reposted here for us to take a look at.
Assuming this occurs with VS up to date with all service packs installed, you might try some of these suggestions. If you haven't tried with service packs, do that first.
What version of Windows are you using? If it is Windows 7, try launching Visual Studio with a compatibility mode and see if that resolves the issue. To do this, make a copy of the normal launch shortcut and go into the Properties dialog and set it to run as Windows Vista.
If this doesn't fix it, then you might also consider:
Checking your PATH environment for any weird settings which might be confusing it, e.g. paths pointing to other SDKs
Any 3rd party VS extensions such as source control, refactoring plugins, wizards etc.
Old versions of .NET or SQL server
Also test if the issue occurs for every kind of project or just certain kinds, e.g. does it happen for all projects? Does it happen in C++, C#, VB.NET projects etc.
You can also attach a debugger to Visual Studio, to see what it's doing. Sometimes a particular .sln will trigger bad behavior or more likely, some third-party add-on.
If you believe that you've gotten VS into a wired state, you can try the following command line switches
devenv.exe /ResetSettings (This will reset the visual studio settings to the defaults)
If that doesn't help, as a last resort, you can try
devenv.exe /ResetUserData
How does Excel VSTO Work? If I create an Excel Workbook solution in Visual Studio 2005 I can then happily code away with full access to the Excel object model and even treat the Excel sheet as a design surface. When I build the solution I get a .XLS file and a .DLL (containing my C# code).
I can now start up the Excel sheet just by double clicking on the .XLS and there is my sheet functioning with all my C# code and any controls I dropped on the sheet etc.
How is the sheet referencing the .DLL? What part of the excel workbook/sheet tells it that it needs to fire up the CLR and host my assembly?
According to this (thanks PintSizedCat) for Excel 2003 the following happens:
The Microsoft Office application
checks the custom document properties
to see whether there are managed code
extensions associated with the
document. For more information, see
Custom Document Properties Overview.
If there are managed code extensions,
the application loads AddinLoader.dll.
This is an unmanaged DLL that is the
loader component for the Visual Studio
2005 Tools for Office Second Edition
runtime. For more information, see
Visual Studio Tools for Office Runtime
Overview.
AddinLoader.dll loads the .NET
Framework and starts the managed
portion of the Visual Studio Tools for
Office runtime.
The Visual Studio Tools for Office
runtime creates an application domain,
sets policy for the application domain
not to trust the My Computer Zone, and
checks the code access security policy
store to find a policy for the
customization assembly.
The .NET Framework validates the
evidence presented by the assembly
against the policy. If it fails, an
error is raised. If it passes, the
process continues.
If the customization uses a deployment
manifest, the Visual Studio Tools for
Office runtime uses it to check for
assembly updates. If any updates are
necessary, they are performed now.
The Visual Studio Tools for Office
runtime loads the assembly into the
application domain.
The Visual Studio Tools for Office
runtime calls the Startup event
handler in your customization
assembly. For more information, see
Visual Studio Tools for Office Project
Events.
In my test project's Excel workbook I have two custom properties:
_AssemblyName, value = *
_AssemblyLocation, value = {533b2c13-a125-418a-bfff-9546b0762807}
I suppose these are the properties which direct the VSTO runtime to my assembly.
This is all done in the Registry, you should be able to find the key in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Excel or your equivelant application. I've more experience with COM Addins which are registered somewhere else in the Registry as well. This key should have a LoadBehaviour item under it which is used to determine how the application is loaded (2 is load manually, 3 is load automatically on startup).
Do you have a Setup Project for your VSTO? Inside there you can see the Registry key that is set, but the Setup program will/should also Register the VSTO in GAC (though don't take my word for it as I'm a bit shakey with VSTO as I said).
Hope this helps, I shall try and find some more information for you.
Edit
You should try reading the following http://msdn.microsoft.com/en-us/library/bb386298.aspx which will give you an explanation of what the addin is. It's really just a wrapper around a COM host which is loaded from the Registry and the VSTO talks to that using some Interoparability code.
Also useful are http://msdn.microsoft.com/en-us/library/23cw517s.aspx (Getting Started with Visual Studio Tools for Office, don't knock it because it says Getting Started in, there's a lot of useful info in there) and http://msdn.microsoft.com/en-us/library/hy7c6z9k.aspx (Which is linked from the first and is an overview of VSTO Addins).