C# COM Interop (Excel Addin) Debugging Failure

[excelthoughts]

Hi,

Sorry about all the detail, but I am desperate. I cannot debug an Excel
Extensibility addin from C# in VS 2005. I have tried many attempts, as
detailed below to restore debugging ability to no avail. I am totally
frustrated and feel like I am the only person who has this problem, but I
know that is not true. So read on, if you're brave...

For the last 7 weeks my C# COM Interop (Excel Addin) Development has stopped.
I built an Excel Addin in C# in Visual Studio 2003, and was able to debug
the managed code successfully for a number of months. The breakpoints stopped
working a few times, but I was able to restore them by reinstalling the Addin
or correcting the Resiliency key added in the registry when Officed addins
are disabled in any Office product.

I then began to attempt to add functionality where my Excel Spreadsheet
could call the managed code. I had this working and could debug starting
from the VBA and then moving to the managed code.

During all the development time, I changed between Debug and Release modes
to test both configurations.

Then all debugging stopped working. In Visual Studio 2003, the breakpoints
said that they would not be hit and that no symbols were loaded. I ran Andy
Pennell's Breakpoint Helper, but it didn't apply. Standard Windows
Applications debug correctly, but COM Interop Addins do not.

I installed Visual Studio 2005 to attempt to fix the issue. The breakpoints
are now solid red, but are still ignored. There are no entries in the Modules
window when I run the Addin in Debug mode.
I created another Addin which is just a stub with 1 message box to run on
OnConnection. The MessageBox never shows. Excel always opens because it is
the App set in "Start External Program", but no managed code is run.

As per
http://spaces.msn.com/members/ilvyanyatka/Blog/cns!1pd2dVb-lPLLY1vqAckmYW8A!182.entry,
I added a config file specifying that the DLL should use v1.1 of the
framework in case this was the problem, and have added CLRVersionForDebugging
Key in the same vain. Neither solution did anything. Also tried creating an
Excel config file as per
http://msdn.microsoft.com/library/d...pgenref/html/gnconsupportedruntimeelement.asp

As per Andrew Whitechapel's advice, I tried sysinternals.com Process
Explorer app and watched the files loaded into Excel process. The file
mscorwks never appeared as it should, and no interop DLLs are loaded. I also
looked at http://support.microsoft.com/kb/908002/ and
http://support.microsoft.com/kb/908004/ (only for VSTO) to no avail.

So, I went down the reinstall windows option and here are the results.
a.Reinstall Windows
b.Install VS 2005
c.Install Office XP
d.Install Office XP PIAs
e.Create stub Extensibility addin with 1 message box.
f.Set Debug program to Excel 2002
g.In debug Configuration
h.build and Install the Addin.
i.Press f5 to run in the debugger.

Received Error Message:
Unable to start debugging. Check for one of the following.

1. The application you are trying to debug uses a version of the Microsoft
..NET Framework that is not supported by the debuuger.
2. The debugger has made an incorrect assumption about the Microsoft .NET
Framework version your appliaction is going to use.
3. The Microsoft .NET Framework version specified by you for debugging is
incorrect.

Please see the Visual Studio .NET debugger documentation for correctly
specifying the Microsoft .NET Framework version your application is going to
use for debugging.

Closes Excel.

I went into HKLM and found that there was no entry in
Software/Microsoft/Office/Addins/OriginalAddin.Connect, so I added them.
However, if I choose View > Registry from within my Addin, there are no
entries in HKLM.
There are entries for my stub Addin. However, the LoadBehavior keeps
reverting back to 2 for the stub addin even after I manually change it in the
Registry.


After changing the LoadBehavior to 3, when I opened Excel by itself, the
addins work. However, they still do not work from the debugger. Neither
mscorwks or any Interop DLLs are loaded in the Excel process.

I have looked at other user problem in the same realm but have not found
answers.
http://groups.google.com/group/micr...nSupportedRuntimeElement.asp#5be636cac099ffb2

http://groups.google.com/group/micr...n"+"c#"+office+loading&hl=en#12496db783c47fcd

Can anyone help before I throw my laptop in the bin?

 

[Thaddaeus Parker]

Ensure when you change from "debug" configuration to "release" configuration
that the compiled files are all going to the correct directory. A lot of
times what happens is that when you change the build configuration, the
location to which the output files are going to are completely different
from one another. One way to overcome some of the issues, is to "uninstall"
the addin and then re-install the add-in using the addin installer project.
This will help "resync" the appropriate .pdb entries to the code that you
are trying to stop at.

Hope this helps,

Thaddaeus.

 

[excelthoughts]

Thanks for that Thaddaeus,

I will make sure I do that from now on. At the moment though, this does not
seem to help. Maybe the pdb files are unsalvageable?
Would the best way to solve this to recreate the addin from scratch and add
in the existing class files to the project? I have tried this a few times
though and the problem remains. Maybe the corruption is somehow contained
within the class files?

Is there some "Reset All" function in Visual Studio apart from Rebuild All?

Thanks,
Andrew

 

[Thaddaeus Parker]

It seems to me that you generated an addin using the PIAs and the VS2003
first. If I am not mistaken and you created a COM add-in with VS2003 and
tried to convert the entire project/solution over to VS2005/VSTO, nothing
will work. I believe it has something to do with the way .NET 2.0 looks at
COM components.

Your best option at this point is to pull the classes that you have already
created with the VS2003 and create a new VS2005 project/solution and include
the appropriate files into the new solution. This way you can monitor and
read breakpoints in your project. Mind that if you created a shim for the
VS2003 project you don't need to bring that over. The only files that you
need to bring over are those classes that create and manage the code-behind
for the Excel workbook.

A couple of good areas look at for help in this endeavor are:
http://blogs.msdn.com/vsto2/
http://msdn.microsoft.com/office/de...a/html/OfficeVSTOWindowsInstallerOverview.asp

http://msdn.microsoft.com/office/un...vsto2005_ta/html/officewhatsnewinvsto2005.asp

 

[- B@rney]

I had a similar situation. To get everything back working I went through all
my classes and the setup project and pasted in new GUIDS created with the
Create GIUD Tools in VS 2003.

If my class didnt have the GUID attribute I added it, to make sure I
controlled what GUID the class should use. Like this:
[GuidAttribute("********-****-****-****-************"),
ProgId("My.AddIn.UtilClass")]
public class UtilClass

To manually install an Add-In without the Wizard generated Deployment
Project you need to xcopy the add-in .dll(s), the extensibility.dll and the
Office.Interop.***.dll's to the client. The you need to regasm you add-in
assembly with the /tlb[:FileName] and /codebase options.

Then you need to add the HKLM[or
HKCU]/Software/Microsoft/Office/<OfficeApp>/Addins/MyAddIn.Connect registry
entries. Look at what you have on your developement machine.

If you need to verify that your .msi file is created correct - download and
install Orca and inspect the file. If the Class table is empty, the .msi file
is corrupt. This often happends if you point the File System part of the
installer project points to your Project Output virtual directory instead of
directly on the files. I've added a PostBuildEvent.cmd to my build that
xcopies my .dlls to a Deploy directory, and then I've pointed the deployment
project to that directory.

HTH