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/subscripti...t/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/subscripti...ult.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/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
