Bardzo duże zużycie pamięci in.NET 4, 0

Natknąłem się na ten problem. I to prawda, że domeny aplikacji są tworzone, a nie czyszczone. Jednak nie polecam powrotu do dziedzictwa. Mogą być czyszczone przez ReleaseSandboxAppDomain ().

LocalReport report = new LocalReport();
...
report.ReleaseSandboxAppDomain();

Kilka innych rzeczy, które również robię, aby posprzątać:

Anulowanie subskrypcji zdarzeń podrzędnych, Jasne Źródła Danych, Pozbądź się raportu.

Nasza usługa windows przetwarza kilka raportów na sekundę i nie ma przecieków.

You might want to

• profil the heap
• Użyj WinDbg + SOS.biblioteka dll do ustalenia, jaki zasób jest wyciekany i skąd jest przechowywany odnośnik

Być może niektóre API zmieniły semantykę lub może być nawet błąd w wersji 4.0 frameworka

Dla kompletności, jeśli ktoś szuka równoważnego ustawienia ASP.Net web.config, to jest to:

  <system.web>
    <trust legacyCasModel="true" level="Full"/>
  </system.web>

ExecuteReportInCurrentAppDomain działa tak samo.

Dzięki temu Social MSDN reference .

Wygląda na to, że Microsoft próbował umieścić raport w oddzielnej przestrzeni pamięci, aby obejść wszystkie wycieki pamięci, a nie je naprawić. W ten sposób wprowadzili kilka twardych awarii, a skończyło się na większej ilości wycieków pamięci w każdym razie . Wydaje się, że buforują definicję raportu, ale nigdy jej nie używają i nigdy nie czyszczą, a każdy nowy raport tworzy nową definicję raportu, zajmując coraz więcej pamięci.

Bawiłem się robiąc to samo: używaj oddzielnego domeny aplikacji i przesłać do niej raport. Myślę, że jest to okropne rozwiązanie i bardzo szybko robi bałagan.

To, co zrobiłem, jest podobne: podziel część raportowania programu na osobny program do raportów. Okazuje się to dobrym sposobem na uporządkowanie kodu.

Najtrudniejszą częścią jest przekazywanie informacji do oddzielnego programu. Użyj klasy Process, aby uruchomić nową instancję programu reports i przekazać wszelkie potrzebne parametry w wierszu poleceń. Pierwszym parametrem powinna być wartość enum lub podobna wartość wskazująca raport, który ma zostać wydrukowany. Mój kod do tego w głównym programie wygląda mniej więcej tak:

const string sReportsProgram = "SomethingReports.exe";

public static void RunReport1(DateTime pDate, int pSomeID, int pSomeOtherID) {
   RunWithArgs(ReportType.Report1, pDate, pSomeID, pSomeOtherID);
}

public static void RunReport2(int pSomeID) {
   RunWithArgs(ReportType.Report2, pSomeID);
}

// TODO: currently no support for quoted args
static void RunWithArgs(params object[] pArgs) {
   // .Join here is my own extension method which calls string.Join
   RunWithArgs(pArgs.Select(arg => arg.ToString()).Join(" "));
}

static void RunWithArgs(string pArgs) {
   Console.WriteLine("Running Report Program: {0} {1}", sReportsProgram, pArgs);
   var process = new Process();
   process.StartInfo.FileName = sReportsProgram;
   process.StartInfo.Arguments = pArgs;
   process.Start();
}

A program raportów wygląda tak:

[STAThread]
static void Main(string[] pArgs) {
   Application.EnableVisualStyles();
   Application.SetCompatibleTextRenderingDefault(false);

   var reportType = (ReportType)Enum.Parse(typeof(ReportType), pArgs[0]);
   using (var reportForm = GetReportForm(reportType, pArgs))
      Application.Run(reportForm);
}

static Form GetReportForm(ReportType pReportType, string[] pArgs) {
   switch (pReportType) {
      case ReportType.Report1: return GetReport1Form(pArgs);
      case ReportType.Report2: return GetReport2Form(pArgs);
      default: throw new ArgumentOutOfRangeException("pReportType", pReportType, null);
   }
}

Twoje metody GetReportForm powinny pobrać definicję raportu, użyć odpowiednich argumentów do uzyskania zbioru danych, przekazać dane i wszelkie inne argumenty do raportu, a następnie umieścić raport w przeglądarce raportów w formularzu i zwrócić odniesienie do formularza. Zauważ, że możliwe jest wyodrębnienie dużej części tego procesu, dzięki czemu możesz w zasadzie powiedzieć "podaj mi formularz dla tego raportu z tego zgromadzenia, używając tych danych i tych argumentów".

Zauważ również, że oba programy muszą być w stanie zobaczyć typy danych, które są istotne dla tego projektu, więc miejmy nadzieję, że wyodrębniłeś swoje klasy danych do ich własnej biblioteki, do której oba te programy mogą współdzielić odniesienie. Nie sprawdziłoby się posiadanie wszystkich klas danych w głównym programie, ponieważ miałby kolistą zależność między programem głównym a programem raportowym.

Nie przesadzaj z argumentami. Wykonaj wszelkie zapytania do bazy danych, których potrzebujesz w programie reports; nie przekazuj ogromnej listy obiektów (która i tak by nie działała). Powinieneś po prostu przekazywać proste rzeczy, takie jak pola ID bazy danych, zakresy dat itp. Jeśli masz szczególnie złożone parametry, może być konieczne przepchnięcie tej części interfejsu użytkownika do programu raportów i nie przekazanie ich jako argumentów w wierszu poleceń.

Możesz również umieścić odniesienie do programu raportów w swoim głównym programie i wynikowego .exe i wszelkie pokrewne .biblioteki DLL zostaną skopiowane do tego samego folderu wyjściowego. Następnie można go uruchomić bez podawania ścieżki i po prostu użyć nazwy pliku wykonywalnego samodzielnie (np.: "SomethingReports.exe"). Możesz również usunąć biblioteki DLL raportowania z głównego programu.

Problem polega na tym, że pojawi się oczywisty błąd, jeśli nigdy nie opublikowałeś raportów program. Po prostu dummy opublikować go raz, aby wygenerować manifest, a następnie będzie działać.

Gdy już to działa, bardzo miło jest zobaczyć, że pamięć Twojego zwykłego programu pozostaje stała podczas drukowania raportu. Pojawia się program raportów, który zajmuje więcej pamięci niż główny program, a następnie znika, usuwając go całkowicie, a główny program nie zajmuje więcej pamięci niż już miał.

Innym problemem może być to, że każda instancja raportu będzie teraz zajmować więcej pamięci niż wcześniej, ponieważ obecnie są to całe oddzielne programy. Jeśli użytkownik drukuje wiele raportów i nigdy ich nie zamyka, bardzo szybko zużywa dużo pamięci. Ale myślę, że jest to nadal dużo lepiej, ponieważ pamięć ta może być łatwo odzyskane po prostu zamykając raporty.

To również sprawia, że Twoje raporty są niezależne od głównego programu. Mogą pozostać otwarte nawet po zamknięciu głównego programu i można je wygenerować ręcznie z linii poleceń lub z innych źródeł.