Debug setup steps

[pkelley]

This will seem very simple to some, but this is my first attempt at writing
an Outlook Add-in, so just need a little nudge in the right direction.

Host dev box:
Windows XP
Outlook 2007
MS Visual Studio 2005

Downloaded from Microsoft and installed:
OutlookAddinTemplates
Outlook2007SampleAddin
- PrepareMeAddinCS
- PrepareMeControlCS
- PrepareMeShimCS
- PrepareMeAddinCSSetup

I successfully rebuilt all 4 "PrepareMe..." projects from the
Outlook2007SampleAddin above.

I right-clicked "PrepareMeAddinCSSetup" and selected "Install" and that
seemed to be successful.

I next wanted to run Outlook and go into DEBUG mode in Visual Studio, but
I'm not sure how to do this.

2 Questions:

1. Given the "PrepareMe..." CS projects above, where do you recommend I
set my first Debug Break-point so that I can watch how execution works inside
an Outlook Add-in?

2. How do I tell Visual Studio 2005 that I want to launch the Outlook
2007 EXE so that the debug versions of "PrepareMe..." are hit?

Thanks for any help

 

[Ken Slovak - [MVP - Outlook]]

Select Project, Properties of the addin project and select the Debug tab.
Use the setting for Start external program and navigate to where Outlook.exe
is stored. Then when you press F5 or start the code in any other way it will
start up Outlook.

If you want to see the addin code running from the InitializeAddin() method
on put your breakpoint on the first executable line in that method. If you
want to see the Extensibility events that fire before InitializeAddin() then
select the Connect class and then select Project, Show All Files. That will
show Connect.Designer. Open that class and you will see the plumbing
underlying the addin. You can then breakpoint in the OnConnection() event
handler, which is what calls to InitializeAddin().

 

[pkelley]

Everything seems to work as you say, but I did run into a configuration
question. I think I know what to do, but to make sure, I thought I should
ask.

My path to Outlook 2007 EXE looks like this:
C:\Program Files\Microsoft Office\Office12\OUTLOOK.EXE

I've got a break-point set on
Connect.Designer.cs

public void OnConnection(object application,
Extensibility.ext_ConnectMode connectMode, object addInInst, ref System.Array
custom)

In Visual Studio, if you right-click on "PrepareMeAddinCSSetup" and choose
"Install", the installer (by default) chooses to install to:
C:\Program Files\Microsoft\Microsoft Office Outlook Sample Prepare Me Add-in
(CS)\

Now in Visual Studio, if I press F5, Outlook fires up just as you say, but I
don't seem to be hitting my break-point in the "PrepareMeAddin..." . I think
it is because the installer is saving the "PrepareMeAddin..." to the wrong
directory. Do you agree?

When you install Outlook Add-ins, are you supposed to install to the same
directory where Outlook EXE is located? So in my case, would it be -
C:\Program Files\Microsoft Office\Office12\OUTLOOK.EXE

Thanks again for your insight.

 

[Ken Slovak - [MVP - Outlook]]

Don't install to the Outlook.exe folder, that's a bad idea.

Does the breakpoint show up as "won't be hit" when the code and Outlook are
running?

Is the addin running? Check in the Outlook Trust Center.

 

[pkelley]

All I needed to do was reboot the XP dev box, and that solved my problem.

I guess in order for an Outlook Add-in to become active, the add-in DLL must
be registered.

I went to see if my add-in was registered, and it was
[HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\PrepareMeAddInCS.Connect]

So I figured a theraputic reboot was in order, and viola! Hit my Break-point!

So gees, it's get'n spooky now. Guess when I create my own add-in for
Outlook, I'm going to have to generate a "registry-editor (.reg)" file.

Am I on the right track?

Anyway, thanks for the help!

 

[Ken Slovak - [MVP - Outlook]]

Usually the setup program has registry settings for the COM addin
registration, either in HKCU or HKLM. In the MS addin samples if you
right-click on the setup project and select View, Registry you should see
where the registration for the addin is set up.

One thing with the shimming in those sample MS addins, it was hacked
together by a developer on the Outlook team and although completely usable
is now superseded by the latest COM Shim Wizard. That is much more automated
when you create your own addins. The current shimming in those samples
requires you to hack the C++ shim code if you want to apply that technique
to your own addins. When you use the shim wizard you don't have to hack the
C++ code.

The shimming is necessary so each shared managed code addin runs in its own
AppDomain. That way exceptions in one addin won't crash other addins running
in the same AppDomain. With no shimming all shared managed code addins share
the default AppDomain, which is less than optimal.