Re: how to correctly release a Reporting Services report (out of memory problem)

Thank you for this, Steven, and I'm sorry for the lag in getting back to
you.

I will check into the calls to Reset(), adn if we still have problems, we
will be in touch with CSS.

Regards

Jeremy


"Steven Cheng[MSFT]" <stcheng@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:9bTpO0TuHHA.360@xxxxxxxxxxxxxxxxxxxxxxxxx
Hi J.Marsch,

Regarding on the VS 2005 reportViewer localReport processing memory issue,
I have performed some research and did found existing bug entry in our
internal catelog. Actually this problem is due to some of the dynamically
generated assembly not able to be unloaded at runtime. And the problem has
been divided into two parts and one is fixed and another part is still not
controllable by design. Here is the detailed description of the issue:

============================
By Design:
The object that is taking up more and more memory is the expression host.
Each time a report is compiled, we create a new expression host assembly
to
evaluate expressions in the report. When the security settings are such
that the expression host runs in the current app domain, this assembly can
never be unloaded. To prevent continuously growing memory, you have two
options. 1 - don't set the security for the current app domain. The
default
is a separate app domain. 2 - Don't call Reset(). When you call reset, we
reset all of the local processing information. If you just set a new
report
definition we will not recompile it, so it will use the old expression
host
and not need to load a new assembly into the appdomain.

Fixed:
I added some better handling for Dispose(). We close memory streams
earlier
now, but we weren't holding a reference to them so it wasn't causing a
problem in this case. Also, with workaround #2 above, we were still
recompiling the report. We don't do that anymore for reports loaded from
the file system or embedded resource.
============================

Also, for your scenario, if the problem is still quite pressure to your
application environment and need a rapid resolution, I suggest you contact
the CSS for further troubleshooting to verify the problem. They'll help
you
perform some further thorough troubleshooting and leverage more resource
on
working out a solution or workaround:

http://msdn.microsoft.com/subscriptions/support/default.aspx

Thanks for your understanding.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================


This posting is provided "AS IS" with no warranties, and confers no
rights.









.

Loading