Unloading spreadsheet Add-ins

[Corey Alix]

Is it possible to free the memory allocated when an addin is
registered/added to a spreadsheet via the AddIn method? I am finding that
the only way to free this memory is to use a seperate ApplicationDomain.
When I create a Spreadsheet control, call Addin one or more times, then
destroy the spreadsheet control, the memory allocated by the Addin is not
released (I am forcing Garbage Collection before checking the available
memory).

 

[Alvin Bruney]

You can call 'System.Runtime.InteropServices.Marshal.ReleaseCom Object' to
release the object explicitly

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006

 

[Corey Alix]

Why does this assertion fail?
Dim lvAddin As Object =
Microsoft.VisualBasic.Interaction.CreateObject(lvProgId)
Debug.Assert(System.Runtime.InteropServices.Marshal.IsComObject(lvAddin),
"This is a COM object")

Thank you Alvin - that does make sense and I hadn't tried that until now.
It doesn't work in my case because the assertion in the code below fails,
and ultimately System.Runtime.InteropServices.Marshal.ReleaseComObject(o)
fails. I am writing my addin in managed code and I *though* I was turning
it into a COM object before invoking AddIn(), but that does not appear to be
the case. I think once I can get the assertion to succeed, your solution
will work. It is strange that the AddIn method expects a COM Automation
addin object, which must be a COM object, yet the IsComObject test is
failing.

Friend Shared Function RegisterType(ByVal piSpreadsheet As
axOWC10.AxSpreadsheet, ByVal piType As System.Type) As Object
Dim lvServices As New
System.Runtime.InteropServices.RegistrationServices
Dim lvProgId As String = lvServices.GetProgIdForType(piType)
Dim lvAddin As Object =
Microsoft.VisualBasic.Interaction.CreateObject(lvProgId)
Debug.Assert(System.Runtime.InteropServices.Marshal.IsComObject(lvAddin),
"This is a COM object")
RegisterAddin(piSpreadsheet, lvAddin)
Return lvAddin
End Function

I am registering the managed class as a COM class via
System.Runtime.InteropServices.RegistrationServices.RegisterAssembly:

Friend Shared Sub RegisterAssembly(ByVal piSpreadsheet As
axOWC10.AxSpreadsheet, ByVal piAssembly As System.Reflection.Assembly)
Dim lvServices As New
System.Runtime.InteropServices.RegistrationServices
If (lvServices.RegisterAssembly(piAssembly,
Runtime.InteropServices.AssemblyRegistrationFlags.SetCodeBase)) Then
Dim lvTypes As System.Type() = piAssembly.GetTypes()
Dim lvType As System.Type
For Each lvType In lvTypes
If lvType.IsPublic Then
RegisterType(piSpreadsheet, lvType)
End If
Next
End If
End Sub

You can call 'System.Runtime.InteropServices.Marshal.ReleaseCom Object'
to release the object explicitly

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------

Is it possible to free the memory allocated when an addin is
registered/added to a spreadsheet via the AddIn method? I am finding
that the only way to free this memory is to use a seperate
ApplicationDomain. When I create a Spreadsheet control, call Addin one or
more times, then destroy the spreadsheet control, the memory allocated by
the Addin is not released (I am forcing Garbage Collection before
checking the available memory).

 

[Alvin Bruney - ASP.NET MVP]

I think you are going about this the wrong way. You should, or the way this
is normally done, add a reference to your COM library to visual studio. The
action creates a runtime callable wrapper. Then, import the appropriate
namespace into your codebehind and begin using the API. If you are not using
Visual Studio, use one of the .NET utilities to create an RCW and proceed
with the namespace import.

Why does this assertion fail?
Dim lvAddin As Object =
Microsoft.VisualBasic.Interaction.CreateObject(lvProgId)
Debug.Assert(System.Runtime.InteropServices.Marshal.IsComObject(lvAddin),
"This is a COM object")

Thank you Alvin - that does make sense and I hadn't tried that until now.
It doesn't work in my case because the assertion in the code below fails,
and ultimately System.Runtime.InteropServices.Marshal.ReleaseComObject(o)
fails. I am writing my addin in managed code and I *though* I was turning
it into a COM object before invoking AddIn(), but that does not appear to be
the case. I think once I can get the assertion to succeed, your solution
will work. It is strange that the AddIn method expects a COM Automation
addin object, which must be a COM object, yet the IsComObject test is
failing.

Friend Shared Function RegisterType(ByVal piSpreadsheet As
axOWC10.AxSpreadsheet, ByVal piType As System.Type) As Object
Dim lvServices As New
System.Runtime.InteropServices.RegistrationServices
Dim lvProgId As String = lvServices.GetProgIdForType(piType)
Dim lvAddin As Object =
Microsoft.VisualBasic.Interaction.CreateObject(lvProgId)
Debug.Assert(System.Runtime.InteropServices.Marshal.IsComObject(lvAddin),
"This is a COM object")
RegisterAddin(piSpreadsheet, lvAddin)
Return lvAddin
End Function

I am registering the managed class as a COM class via
System.Runtime.InteropServices.RegistrationServices.RegisterAssembly:

Friend Shared Sub RegisterAssembly(ByVal piSpreadsheet As
axOWC10.AxSpreadsheet, ByVal piAssembly As System.Reflection.Assembly)
Dim lvServices As New
System.Runtime.InteropServices.RegistrationServices
If (lvServices.RegisterAssembly(piAssembly,
Runtime.InteropServices.AssemblyRegistrationFlags.SetCodeBase)) Then
Dim lvTypes As System.Type() = piAssembly.GetTypes()
Dim lvType As System.Type
For Each lvType In lvTypes
If lvType.IsPublic Then
RegisterType(piSpreadsheet, lvType)
End If
Next
End If
End Sub

You can call 'System.Runtime.InteropServices.Marshal.ReleaseCom Object'
to release the object explicitly

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------

Is it possible to free the memory allocated when an addin is
registered/added to a spreadsheet via the AddIn method? I am finding
that the only way to free this memory is to use a seperate
ApplicationDomain. When I create a Spreadsheet control, call Addin one or
more times, then destroy the spreadsheet control, the memory allocated by
the Addin is not released (I am forcing Garbage Collection before
checking the available memory).