R
RichardZ
I know this is a much-queried issue.
I have a COM AddIn written in C# (.NET v1.1) targeted primarily at Excel &
Powerpoint (mainly XP, some 2003). This AddIn acts as a loader for plugin
assemblies (again C#) that extend the functionality of the host Office app.
The plugins make extensive use of the hosts' object models, and often contain
fairly complex object hierarchies themselves. They add their own menu system
to the host that present a number of Windows forms dialog boxes to the user.
My problem is that both hosts sometimes stay resident in memory (though the
UI is shut down). However, this behaviour is occassional. Also, when I'm
debugging using Visual Studio, generally the host shuts normally and the
debugger detaches; sometimes the debugger detaches but the host stays
resident in memory; very occassionally the host stays resident and the
debugger stays attached.
I have tried ripping my code apart and reconstructing it, but the problem
creeps back in at no particular point. I have used Marshal.ReleaseCOMObject,
GC.Collect and GC.WaitForPendingFinalizers, indeed quite liberally. I have
cut back on the references that I store in my C# code to objects belonging to
the host to simply the host itself, and each CommandBarControl that I add to
the host. I release these very politely when the AddIn shuts down.
I am going nuts trying to sort this out. It's a bit of a show-stopper as far
as production code goes. Naturally I want to blame the tools, and am looking
an explanation along the lines of the Office XP PIAs being fundamentally
flawed (well, they are pretty vile) or that this is an unacknowledged issue
in .NET 1.1 COM Interop against the Office suite etc etc.
Any takers?
I have a COM AddIn written in C# (.NET v1.1) targeted primarily at Excel &
Powerpoint (mainly XP, some 2003). This AddIn acts as a loader for plugin
assemblies (again C#) that extend the functionality of the host Office app.
The plugins make extensive use of the hosts' object models, and often contain
fairly complex object hierarchies themselves. They add their own menu system
to the host that present a number of Windows forms dialog boxes to the user.
My problem is that both hosts sometimes stay resident in memory (though the
UI is shut down). However, this behaviour is occassional. Also, when I'm
debugging using Visual Studio, generally the host shuts normally and the
debugger detaches; sometimes the debugger detaches but the host stays
resident in memory; very occassionally the host stays resident and the
debugger stays attached.
I have tried ripping my code apart and reconstructing it, but the problem
creeps back in at no particular point. I have used Marshal.ReleaseCOMObject,
GC.Collect and GC.WaitForPendingFinalizers, indeed quite liberally. I have
cut back on the references that I store in my C# code to objects belonging to
the host to simply the host itself, and each CommandBarControl that I add to
the host. I release these very politely when the AddIn shuts down.
I am going nuts trying to sort this out. It's a bit of a show-stopper as far
as production code goes. Naturally I want to blame the tools, and am looking
an explanation along the lines of the Office XP PIAs being fundamentally
flawed (well, they are pretty vile) or that this is an unacknowledged issue
in .NET 1.1 COM Interop against the Office suite etc etc.
Any takers?