When you run ReportViewer.exe, the following files are installed in the Global Assembly Cache folder on the deployment computer.
- Microsoft.ReportViewer.Common.dll
- Microsoft.ReportViewer.ProcessingObjectModel.dll
- Microsoft.ReportViewer.WebForms.dll
- Microsoft.ReportViewer.WinForms.dll
- Microsoft.ReportViewer.DataVisualization.dll
-------------
We develop software on MS Visual Studio 8 and we are facing serious problems with MS Report Viewer's memory leaks (WinForms Application).
-------------
Posted by Microsoft on 2/2/2010 at 3:43 PM
Thank you for your feedback.
The issue that you have reported has been fixed in Visual Studio 2010.
-------------
Posted by Sautin on 2/10/2010 at 10:27 AM
No the issue has not been fixed in VS2010, I just downloaded it and redeveloped my class library that generates PDF reports using Microsoft ReportViewer Control version 10. Every time that I call LocalReport.RefreshReport() Method, my memory jumps significantly(expected for generation of the report) but even after disposing of the reportviewer and cleaning it out, my memory footprint never returns to what it was. This is becoming really disappointing and may cause us to use someone elses technology to render reports for our clients.
-------------
Posted by Cyberlogic on 2/17/2010 at 8:13 AM
Hi there, we just tried the Report Viewer files from VS2010 RC1 Ultimate edition (By referencing Microsoft.ReportViewer.WinForms.dll & Microsoft.ReportViewer.Common.dll in our projects) in VS2008 and the Report Viewer seems to work FINE now!
We noticed that there is no delays from memory leaks and that the application works normally.
We got some help from another post in MS Connect: https://connect.microsoft.com/VisualStudio/feedback/details/510243/report-viewer-has-memory-leak-in-local-report-mode
-------------
If Session.Count > 0 Then
For i As Integer = 0 To Session.Count - 1
If i < Session.Count AndAlso Not Session(i) Is Nothing AndAlso Session(i).GetType().ToString() = "Microsoft.Reporting.WebForms.ReportHierarchy" Then
Session.RemoveAt(i)
End If
Next
End If
-------------
Visual Studio 2010
The ReportViewer in VS 2010 is a multi-targeted assembly. That means that is can be loaded into a .Net 3.5 or a .Net 4.0 application. When running under .Net 3.5, all of the same rules and methods noted above are applicable. However, the CLR security team made changes to code access security in .Net 4.0, so there are corresponding changes in the ReportViewer as well:
- Executing in the current AppDomain is no longer supported, so using a sandbox is the default mode when running in .Net 4.0. Two new methods have been added to better control the permissions of the sandbox AppDomain so that you don’t see any loss of functionality: AddFullTrustModuleInSandboxAppDomain and SetBasePermissionsForSandboxAppdomain.
- ExecuteReportInCurrentAppDomain, AddTrustedCodeModuleInCurrentAppDomain, and ExecuteReportInSandboxAppDomain have been marked as obsolete. While it is perfectly acceptable to use them in a .Net 3.5 application, they won’t have any effect when you compile for .Net 4.0. Going forward, we recommend using the sandbox AppDomain even under .Net 3.5 because setting the correct security policy on the current AppDomain is an error prone task. The new methods will work under both frameworks and is the best approach if you want to write in a framework agnostic way.
If you do nothing, the default behavior under .Net 4.0 will result in the same permissions for the expression host as the default behavior in VS 2008. You will be running in a sandbox AppDomain (versus the default of the current AppDomain in VS 2008), but the permissions for the expression host will be the same.
As part of the security changes to the CLR in .Net 4.0, an application configuration flag, NetFx40_LegacySecurityPolicy, can be specified to use the .Net 3.5 security model in .Net 4.0. If this flag is specified, the report viewer will behave just as it would under .Net 3.5, meaning that the obsolete methods will function correctly.
Regardless of which framework version you use with the VS 2010 report viewer, the issue surrounding the sandbox AppDomain leak has been fixed. The sandbox AppDomain is shared resource across multiple instances of the viewer. A new AppDomain is created periodically (if there is a need) and used by all local mode requests in the process. Once all reports referencing the old AppDomain have completed, the old domain will unload.
-------------
报表难点
1 RDLC 数据量大的时候，大量占用内存，超过800M。
2 RDLC 占用的内存没有释放
报表在ReportViewer中呈现的时候占用大量的内存？精简报表的设计？
只生成PDF或Excel，不在ReportViewer中呈现？
使用 ReportViewer 2010?
consider asking for a nice new machine with >= 8 Gigabytes of RAM and a 64-bit operating system.
使用报表服务器？--- 占用内存是否还是很大？
使用水晶报表？ --- 不可行（价格昂贵，重新设计，VS2010中无水晶报表）
使用Access2007/2010的报表功能？ ---- 不可行
-------------
http://blogs.msdn.com/brianhartman/archive/2010/02/18/expression-evaluation-in-local-mode.aspx
Deploying Reports and ReportViewer Controls
http://msdn.microsoft.com/en-us/library/ms251723.aspx
http://stackoverflow.com/questions/2486118/report-viewer-out-of-memory-exception