Laden...

Nicht benötigte Methoden beim Kompilieren aus DLL entfernen

Erstellt von Cornflake vor 8 Jahren Letzter Beitrag vor 8 Jahren 3.117 Views
C
Cornflake Themenstarter:in
142 Beiträge seit 2007
vor 8 Jahren
Nicht benötigte Methoden beim Kompilieren aus DLL entfernen

Hallo Leute

Bei meinen Projekten haben sich mit der Zeit nützliche immer wieder verwendete Methoden angesammelt. Diese liegen bei mir in einem DLL Hilfsmethoden-Projekt, dass ich bei anderen Projekten einbinde.
Natürlich brauche ich bei den Projekten nicht jede Hilfsmethode aus meinem DLL Hilfsmethoden-Projekt.

Daher die Frage: ?(
Kann beim Kompilieren nicht benötigter Code aus eingebundenen DLLs entfernt werden?
Oder kann ich anderweitig im Vorfeld per Script etc. aus einem Projekt nur die benötigten Methoden mit Zwischenverweisen extrahieren?

Grüße Cornflake

3.003 Beiträge seit 2006
vor 8 Jahren

Resharper kann das (in Teilen). Allerdings stellt sich die Frage, warum du eine vielseitige Bibliothek anlegst, wenn du sie dann nicht benutzen möchtest. Vielleicht mal deine Bibliotheken reorganisieren? 😃

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

T
2.219 Beiträge seit 2008
vor 8 Jahren

Glaube nicht, dass dies funktioniert.
Sonst würde man ja den Zweck der Klassenbibliothek entfremden.
Den gerade die Verteilung oft benötigtem Code ist ja gerade der Sinn davon.
Es stellt sich die Frage was du damit bezwecken willst.
Nur um ein paar kb Speicherplatz zu sparen, macht es kaum Sinn größeren Aufwand zu betreiben.

Ansonsten müsstest du diese nicht benötigten Funktionen wiederum in eine weitere DLL auslagern oder den Code selbst entfernen.
Aber alles was du in eine Klassenbibliothek packst, wird dann auch ohne Änderungen beim kompilieren dort reingeprest.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.807 Beiträge seit 2008
vor 8 Jahren

Davon abgesehen, dass das Null dem entspricht, wofür eine Klassenbibliothek gedacht ist, funktioniert das.
Aber: Visual Studio kann dies nicht von Haus aus (macht auch kein Sinn) und ReSharper kann das prinzipiell - aber ohne Beachtung von Reflection.

F
10.010 Beiträge seit 2004
vor 8 Jahren

Xamarin macht das bei Android Programmen, speziell beim zusammenstellen der Apps mit der Runtime spart das schon einiges an speicher,

ABER das führt zu so vielen Problemen wenn man Reflection benutzt ( was aber bei fast jedem ORMapper nötig ist) das man das meist ausschaltet.

C
Cornflake Themenstarter:in
142 Beiträge seit 2007
vor 8 Jahren

Hallo Leute
Danke für eure Antworten. Im Prinzip werde ich wohl das dann manuell anpassen.
Ich habe nur aktuell den Fall, dass ich eine SQLite Import Methode geschrieben hatte, die als Hilfmethode bei einigen Projekten zum Einsatz kommt, aber eben nicht bei allen. Jedenfalls benötigt dieser schnelle Import die SQLite.exe und die wird daher bei dem Hilfmethodenklasse mitgegeben und beim kompilieren auch in den Ausgabeordner kopiert. Nur für mein jetziges Projekt brauche ich diese z.B. nicht.

Werde daher vllt. nur diesen Part ändern, dass die SQLite.exe nicht immer mit in den Ausgabeordner kopiert wird, wenn nicht vorhanden.

Am besten wäre es wohl die Hilfsmethodenklasse so zu strukturieren, dass bestimmte Teile deaktiviert werden können. Habe nur keine Ahnung wie ich das am besten mache. Sollte ich eine Hilfmethoden Solution anlegen und da zu jedem Thema (Datenbanken, Controls, Dateihandling,...) ein eigenes Projekt anlegen, dann kommen zum Schluss x Dll Dateien raus und am liebsten wäre es mir eigentlich, wenn ich nur eine Dll habe (auch wenn intern bei der Programmierung gerne viele Klassen zur Strukturierung eingesetzt werden). Noch besser wäre es z.B., wenn nur die wirklich benötigten Hilfsmethoden mit in der exe Datei stehen, da ich die separat eigentlich nicht benötige.
Dass hätte für mich den Vorteil, dass ich zum Weitergeben des Programms nur die eine Exe benötige (und .NET Framework vorausgesetzt). Denn die Benutzer interessiert es nicht, wie toll ich Klassenbibliotheken verwende. Denen wäre einfach nur eine Datei kopieren am liebsten.

@FZelle: Ist das von Xamarin ein separates Tool, dass dies zusammenstellt?

Grüße Cornflake

1.040 Beiträge seit 2007
vor 8 Jahren

Ich würde die SQLite-Funktionalität in eine weitere Hilfs-DLL auslagern. Dann brauchst du sie nur da einbinden, wo du sie benötigst.

Und es gibt weiterhin Tools, die dir mehrere DLLs zusammenfassen können, was du dann schlussendlich haben möchtest...
EDIT: ILMerge

F
10.010 Beiträge seit 2004
vor 8 Jahren

@Cornflake:
Nein, das ist in deren Linker eingebaut.

Aber wozu meinst du sqlite.exe zu benötigen?
Alles was damit gemacht werden kann, kann man auch mit System.Data.SQLite machen.

C
Cornflake Themenstarter:in
142 Beiträge seit 2007
vor 8 Jahren

@FZelle ok schade.

Naja wenn ich eine csv Tabelle importieren möchte, dann gibts den Importaufruf von sqlite.exe per Commandzeile.
sqlite> .mode csv
sqlite> .import C:/work/somedata.csv tab1

Diese Art des Imports ist bei sehr langen CSV Dateien wesentlich schneller, als bei anderen rein C# basierenden Aufrufen. Dazu wird aber die sqlite.exe benötigt.

Jedenfalls bei meinem aktuellen Projekt brauch ich den nicht, daher werde ich die Methode auskommentieren.

F
10.010 Beiträge seit 2004
vor 8 Jahren

Diese Art des Imports ist bei sehr langen CSV Dateien wesentlich schneller, als bei anderen rein C# basierenden Aufrufen. Dazu wird aber die sqlite.exe benötigt.

Das halte ich für ein Gerücht.
Das ist nur deswegen schneller weil du wahrscheinlich bei der manuellen Übernahme nicht richtig vorgehst.
Also transaction öffnen, parameter anlegen und in einem tighten loop die daten importieren.
http://stackoverflow.com/questions/1711631/improve-insert-per-second-performance-of-sqlite

T
2.219 Beiträge seit 2008
vor 8 Jahren

@Cornflake
Für dein BulkCopy brauchst du die sqlite.exe aber nicht.
Die Funktion dafür bietet dir die SQLite C# Lib schon.
Diese ist auch nicht wesentlich schneller/langsamer als die .exe Lösung.
Den beide laufen am Ende über den selben Code.

Die Frage ist nur, wie deine alte Import Lösung aussah.
Ggf. war diese einfach nicht sauber umgesetzt und hat sich deshalb selbst ausgebremst.
Oder hast du ungeprüft einfach irgendwo gelesen, dass die exe Lösung schneller sein?

Hilf Link:
http://procbits.com/2009/09/08/sqlite-bulk-insert

Bei Sqlite solltest du wenn möglich bei Insert, Update, Delete und co. auf Transaktionen setzen.
Diese beschleunigen in den meisten Fällen die Verarbeitung enorm.
Entsprechende Beispiele und Benchmarks findest du auch bei Google zu hauf.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.807 Beiträge seit 2008
vor 8 Jahren

Naja, das kommt drauf an. Auch postgreSQL (und Oracle?) können über CSV wesentlich schneller importieren.
Würde mich nicht wundern, wenn das bei SQlite ebenso so wäre. COPY läuft auch intern anders ab.

C
Cornflake Themenstarter:in
142 Beiträge seit 2007
vor 8 Jahren

Hi

Thx für eure Antworten.
Habe leider nicht mehr die Seite gefunden, bei der dieser Geschwindigkeitsvergleich vorgenommen wurde. Bin mir aber sicher das dort stand, dass per sqlite3.exe der Import wesentlich schneller als der Import per C# sein soll.
Vllt ist das inzwischen auch anders.

16.807 Beiträge seit 2008
vor 8 Jahren

Ich bin mir sicher, dass sich das nicht auf einen INSERT-Befehl bezieht....

F
10.010 Beiträge seit 2004
vor 8 Jahren

Wie ich das INet kenne, war das jemand der ohne Transactions und mit ständig neuen Commands gearbeitet hat.

F
51 Beiträge seit 2011
vor 8 Jahren

schau dir mal Fody an, aber da musst du dir diesen Fall selbst schreiben

C. Anders