250Mb Heap limit for VSTOAddin+Outlook?

[rchf]

Is there and OTHER-than-hardware-determined limit to available RAM usable by
a VSTO Addin operating almost entirely in managed code? What I am seeing is
that at about 250Mb (1 Gb available on the hardware), the Addin quits with a
"Out of Memory" exception.

If this limit is documented somewhere a pointer would be great.

Thank you.

 

[SvenC]

Hi,

Is there and OTHER-than-hardware-determined limit to available RAM usable
by
a VSTO Addin operating almost entirely in managed code? What I am seeing
is
that at about 250Mb (1 Gb available on the hardware), the Addin quits with
a
"Out of Memory" exception.

How do you calculate the 250MB? Is that the working set of Outlook.exe?
What operation does throw that exception?

Try to explicitly call ReleaseComObject on all COM wrapper objects as soon
as you do not need them anymore, otherwise the wrapped COM objects live
until the next garbage collection.

 

[rchf]

Thanks fro the reply Sven.

The memory was filled by loading a sizable string-filled data structure into
memory. The 250Mb is the memory that Task Manager reports is consumed by
Outlook.exe.

We worked around this problem by "not doing what hurt" and keeping less
content in memory. But knowing about a limit on the size of Outlook.exe or
of an associated VSTO Addin would be good - hence the question.

Our stuff is largely managed code so ReleaseComObject was probably not the
problem but we aren't totally sure. Thanks for the tip.

Best,
R

 

[SvenC]

Hi,

We worked around this problem by "not doing what hurt" and keeping less
content in memory. But knowing about a limit on the size of Outlook.exe
or of an associated VSTO Addin would be good - hence the question.

Our stuff is largely managed code so ReleaseComObject was probably not
the problem but we aren't totally sure. Thanks for the tip.

But VSTO are wrappers around COM objects, so there still might be some COM
objects waiting to be released. But I am not sure if ReleaseComObject can be
used on the VSTO wrapper classes.

Because of the lack of control I chose a C++ Shared COM Addin approach in
favor of VSTO. A bit more code but not too hard.