Laden...

dll einbindung zur laufzeit

Erstellt von public_override vor 20 Jahren Letzter Beitrag vor 20 Jahren 7.954 Views
P
public_override Themenstarter:in
32 Beiträge seit 2003
vor 20 Jahren
dll einbindung zur laufzeit

ich würde gerne meinem programm die fähigkeit hinzufügen, dass es automatisch sämtliche .dll dateien, die sich während des programmstarts im verzeichnis befinden dynamisch einbindet, egal, wie sie heißen, und egal wie viele, und außerdem sich von innerhalb der .exe datei einzelne .dll's dazu- und abschalten lassen.
also ein plug-in system auf .dll-basis.

ich hab mich mal in die zweite ausgabe von inside c# von microsoft press zum thema assemblys vertieft, doch da wird, soweit ich sehen kann nur die einbindung über compileroptionen

csc /t:library DLLTestServer.cs
csc DLLTestClient.cs /r:DLLTestServer.dll

beschrieben, oder evtl. irgendetwas mit

[DLLImport ("irgendeine.dll")]

allerdings müsste man dann bei der einbindung einer beliebigen dll sowas schreiben

string Dateiname = "irgendeine.dll";
[DLLImport (Dateiname)]

ich weiß aber nicht ob das überhaupt geht, hab auch keine genauere beschreibung davon gefunden. wenn es eine möglichkeit gibt, per programm abzufragen, ob .dll-dateien vorhanden sind, und diese in z.b. einer listbox aufzulisten, um sie vom benutzer aktivier- und deaktivierbar zu machen, bitte ich um erkärung.

ich hasse freizeit,... sinniert man doch nur über dinge die man tun könnte, hätte man mehr freizeit

C
980 Beiträge seit 2003
vor 20 Jahren

DLLImport brauchst du nur für "klassische" DLLs, Mit .NET DLLs kannst du hingegen "richtig" arbeiten ... (Stichwort Reflection)

Schau dir mal die System.Assembly Klasse an, u.a. "Assembly.LoadFrom" ...

Gibt auch haufenweise Artikel dazu im web:

http://www.entwickler.com/itr/online_artikel/psecom,id,390,nodeid,31.html

http://www.codeproject.com/csharp/livecodedotnet.asp

http://www.c-sharpcorner.com/Code/2002/April/LoadingAssemblyInfo.asp

...

P
public_override Themenstarter:in
32 Beiträge seit 2003
vor 20 Jahren

vielen dank, hat mir sehr geholfen

... ich würd sagen... 5 punkte
(gibt ja noch kein gnolledsch-konto, aber die haste schon mal)

tja, ich find immernoch, dass das einzige, was beim programmieren laggt ist die doku, obwohl es seit 2000 schon erhebliche fortschritte gibt. da ist man echt auf die community angewiesen, die haben zusammengerechnet ein paar mehr augen und köpfe als man selbst.

ich hasse freizeit,... sinniert man doch nur über dinge die man tun könnte, hätte man mehr freizeit

C
980 Beiträge seit 2003
vor 20 Jahren

😮opsoopsoopsoopsoops::oops:
Dokumentation schreiben ist halt meistens nicht wirklich attraktiv;

EDIT!!!!

VERSEHENTLICH EDITIERT STATT ZITIERT, BITTE NEU SCHREIBEN @CDR
Hatte nur noch den obigen Teil!!!!!

TUT MIR LEID!
CODE-HACKER!!!!

😮opsoopsoopsoopsoopsoopsoopsoopsoops:

V
842 Beiträge seit 2003
vor 20 Jahren

Original von cdr

Dokumentation schreiben ist halt meistens nicht wirklich attraktiv;

Dokumentation schreiben soll nicht attraktiv sein, sondern es soll dafür sein um zu sehen was gemacht wird bzw. warum es so gemacht wird. Wenn man was nicht versteht sondern erst über eine Community oder sonstigem erfährt so sollte man dies ausführlich Dokumentieren.
Ich habe vom 1. bis zur vorletzten Übung des 2. Semesters auch nicht dokumentiert, deswegen wusste ich z.B. bei ner Laufschrift mehr wofür was ist bzw. was was macht.
Jetzt wo ich dabei bin dabei bin mir die MFC anzueignen, mache ich es so das ich alles Programmiere (Beispiele, Übungen, Tests) und alles nochmal für mich im Programm mitdokumentiere (sogar die Beispiele die im Buch beschrieben werden) damit ich nicht immer erst um Buch Nachschlagen muss.
Außerdem mache ich es mittlerweile so, wenn ich mir etwas schreibe und da Schritt für Schritt irgendwelche Klassen und Methoden entwerfe, dann entwerfe ich mir kleine Testumgebungen wo alles mehr oder minder auf Herz und Nieren geprüft wird (spätere Fehler sind nie ausgeschlossen).

Vielleicht sollte ich mal einen Thread mit Dokumentationsrichtlinien eröffnen, wo ich die wichtigsten Regeln reinschreibe mit Beispielen und was nützlich und was überflüssig ist. Dazu vielleicht wie man trotz Doku sich schnell in ein neues Programm oder was auch immer einarbeiten kann. Was haltet ihr davon? Vllt. werden dadurch ja mehr Leute zur Dokumentation ihrer Sachen angereizt ich kenne viele die es immer noch gar nicht machen oder sehr dürftig trotz bekannter Dokurichtlinien.

Code-Hacker

C
980 Beiträge seit 2003
vor 20 Jahren

Sooo wichtig war das Posting auch wieder nicht; ausserdem hab ich inzwischen schon wieder vergessen was ich geschrieben hatte, also ... 😉

(ging u.a. darum, dass Dokumentationsschreiben halt nicht sehr attraktiv ist wie ich bei meinen eigenen Projekten merke; ausser der per NDoc automatisch generierten referenz ist sie nur sehr spährlich vorhanden ... dass aber MS sich durch die Kolumnen, Spezialseiten, Blogs, User Groups etc. sich neulich aber immerhin recht mühe gibt, eben solche Communities aufzubauen)

Ja, öffne einen solchen Thread. Vielleicht werd ich mir dann auch mal ein insich geschlossenes Dokumentationskonzept aneignen. Zu meinem Math.NET Projekt werde ich jedenfalls öfters nach mehr Dokumentationsmaterial gefragt - verständlich, da man mit der Referenz kaum die Konzepte und Paradigmen der Bibliothek verstehen kann ...

P
public_override Themenstarter:in
32 Beiträge seit 2003
vor 20 Jahren

ja, genau dafür bin ich nämlich auch.
die leute, die selbst programmieren, schreiben eigentlich immer die beste doku. meistens, so war das auch bei mir, verwendet man die zeit allerdings lieber zum programmieren, als zum kommentieren und hat dann später, wenn man mal an einem projekt einige zeit nichts gemacht hat, viel arbeit damit, sichwieder ins problem reinzudenken.
also: besser gleich ne doku mit hochziehen.

übrigens, was ich an manchen tutorials hasse ist, dass die den quellcode immer so zerreissen, um dazwischen irkendwelche erklärungen reinzuschreiben.

zb:
also hier kommt jetzt folgende funktionsdefinition

public int durch(int ein)
{
.
.
.
}

und im folgenden werden diese operationen durchgeführt

...
int aus = ein;
return aus;
...

anstelle dessen hätte ich es lieber so:

public int durch(int ein) // hier ist die funktionsdefinition
{
int aus = ein; // hier wird ne variable definiert und zugewiesen
return aus; // dier wird der rückgabewert festgelegt
}

hier sieht man nänlich viel besser, in welchem kontext die anweisungen stehen. alles andere ist kalter kaffe. (IMHO)

ich hasse freizeit,... sinniert man doch nur über dinge die man tun könnte, hätte man mehr freizeit

H
704 Beiträge seit 2003
vor 20 Jahren

Real programmers do not comment their code. If it was hard to write it should be hard to read :lol:

public_override: finde ich nicht so, mit einer solchen Vorgangsweise wird man eher zum selbstständigem Denken angeregt

[last.fm](http://www.last.fm/user/hauptmanAlpha/)
C
980 Beiträge seit 2003
vor 20 Jahren

Ich bevorzuge eine Kombination von beidem: das ganze am Stück mit inline Kommentaren, und daneben einige speziell wichtige Elemente noch mal isoliert behandelt.

Mit Dokumentation meine ich übrigens nicht einfach nur Komentare, sondern alle drei Elemente:

  1. Komentare innerhalb des Codes sind gut um die Funktionsweise eines Algorithms zu erläutern -> also für den prozeduralen Teil.

  2. Die Verwendung von (isolierten) Klassen und Methoden erläutert man in der inline XML Dokumentation; mit der kann man ja dann auch bequem mittels NDoc eine Referenz zb. im MSDN Style generieren -> also für den objektorientierten Teil.

Mit diesen beiden Teilen hat man aber (zumindest bei etwas grösseren und abstrakteren Systemen) noch überhaupt nichts verstanden. Der eigentlich wichtigste Teil also:

  1. Wie das ganze intern Organisiert ist, wie man welche Probleme damit angehen und lösen kann, Datenfluss, Innere Zustände und -Übergänge, Abhängigkeiten etc., also all die Konzepte die hinter dem Projekt stehen. Dies macht wohl nur in einer externen Dokumentation Sinn, aber genau das ist auch der Punkt an dem es oft mangelt (auch bei meinen Projekten..). In den meisten Fällen unterstützen diesen Bereich auch gute UML Diagramme...
P
public_override Themenstarter:in
32 Beiträge seit 2003
vor 20 Jahren

Original von Hauptmann

Real programmers do not comment their code. If it was hard to write it should be hard to read :lol:

public_override: finde ich nicht so, mit einer solchen Vorgangsweise wird man eher zum selbstständigem Denken angeregt

zum selbständigen denken kann man nur diejenigen anregen, die genau schon wissen, wie die semantik der sprache funktioniert.
neulinge hingegen verwirrt man damit nur. zum selbst-studium einer programmiersprache sind eben gut kommentierte zusammenhängende quellcodes unerlässlich.

ich gehe z.b. so vor, dass ich ein problem zu lösen habe, und mir dann die doku durchsuche nach möglichen vorgehensweisen. habe ich schließlich eine bibliotheksfunktion oder eine klasse gefunden, die meine aufgabe bewältigen könnte, dann weiß ich immer noch nicht, wo, in welchem programmteil ich diese funktion oder klasse einsetzen muss.
würde ich z.b. assembler programmieren, oder auch noch das gute alte quickbasic, oder andere prozedurale sprachen, dann wäre alles klar, aber gerade beim oo-programmieren, muss man wissen, was, wen aufruft, und welchen wert an wen weitergibt. und das geht halt nur, wenn man das programm (muss nicht genau das programm sein, was man selbst programmieren möchte, aber ein exemplarisches beispiel der anwendungsweise einer funktion) in seiner gesamtheit sieht.

ich hasse freizeit,... sinniert man doch nur über dinge die man tun könnte, hätte man mehr freizeit

H
704 Beiträge seit 2003
vor 20 Jahren

Original von Hauptmann

Real programmers do not comment their code. If it was hard to write it should be hard to read :lol:

public_override: finde ich nicht so, mit einer solchen Vorgangsweise wird man eher zum selbstständigem Denken angeregt

zum selbständigen denken kann man nur diejenigen anregen, die genau schon wissen, wie die semantik der sprache funktioniert.
neulinge hingegen verwirrt man damit nur. zum selbst-studium einer programmiersprache sind eben gut kommentierte zusammenhängende quellcodes unerlässlich.

ich gehe z.b. so vor, dass ich ein problem zu lösen habe, und mir dann die doku durchsuche nach möglichen vorgehensweisen. habe ich schließlich eine bibliotheksfunktion oder eine klasse gefunden, die meine aufgabe bewältigen könnte, dann weiß ich immer noch nicht, wo, in welchem programmteil ich diese funktion oder klasse einsetzen muss.
würde ich z.b. assembler programmieren, oder auch noch das gute alte quickbasic, oder andere prozedurale sprachen, dann wäre alles klar, aber gerade beim oo-programmieren, muss man wissen, was, wen aufruft, und welchen wert an wen weitergibt. und das geht halt nur, wenn man das programm (muss nicht genau das programm sein, was man selbst programmieren möchte, aber ein exemplarisches beispiel der anwendungsweise einer funktion) in seiner gesamtheit sieht.

ich meinte jetzt nich das Quellcodeauskommentieren sondern deine Aussage bzgl. der Tutorials

Kommentieren: ICh finde man sollte in kurzen knappen Sätzen kommentieren

[last.fm](http://www.last.fm/user/hauptmanAlpha/)
V
842 Beiträge seit 2003
vor 20 Jahren

Da ich vorgestern nur ganz kurz und gestern gar nicht zuhause war, habe ich mir meine Doku-/Kommentierungsrichtlinien nicht mehr ansehen können, aber ich weiß noch etwa wie es sein sollte.

Kommentierung:
Kommentierung einzelner Zeilen kurz, knapp und so selten wie möglich und so weit wie möglich eindeutige Bezeichner wählen, also das man schon fast im Namen sehen kann was die Variable macht bzw. wofür sie steht.

Dokumentierung:
Bei Prozeduren und Funktionen war es so, das wir da vor der Funktion eine große Zusammenfassung der Funktion gemacht haben, d.h. Name der Funktion, Beschreibung der Funktion, also was sie macht, Parameter Beschreibung wofür sie sind und notieren ob sie etwas zurückliefern. Variablen und evtl. Konstanten Beschreibungen die in der Funktion deklariert wurden. Datum und Uhrzeit der Erstellung bzw. letzten Änderung.
Auch hier bei der Dokumentierung gilt die Regel(n) der Kommentierung, also bei sich selbsterklärenden Variablennamen z.B. counter/zaehler braucht man nicht unbedingt schreiben das sie als Zähler dienen oder so, solche Sachen sollten sich von selbst klären.

Eine Dokumentierung kann auch nervig sein im Programm, so dass es schöner ist sie auszulagern, da man sowieso bei der Dokumentierung den Namen der Funktion angibt. Und sowas direkt neben der Funktion statt über der Funktion zu haben ist doch schon wesentlich besser.

Ich denke auch, dass egal wie gut man Programmieren kann ohne auszuprobieren und ganz ohne eine Erklärung nicht immer alles einfach zu verstehen ist und das man ganz ohne Kommentare vllt. sogar gar nicht versteht was gemacht wird und warum das so gemacht wird.

Code-Hacker

C
980 Beiträge seit 2003
vor 20 Jahren

Original von Code-Hacker

Dokumentierung:
Bei Prozeduren und Funktionen war es so, das wir da vor der Funktion eine große Zusammenfassung der Funktion gemacht haben, d.h. Name der Funktion, ... (cut)

Per Design Guidelines ist dieser Teil (Teil 2 in meinem obigen Posting) per inline XML Dokumentation zu dokumentieren ... das sieht dann zb. so aus:

/// <summary>
/// creates a new parameter collection with all parameters substituted.
/// </summary>
/// <param name=>original>>the term to look for</param>
/// <param name=>replacement>>the replacement for the original term</param>
/// <returns>the substituted collection</returns>
public Parameters Substitute(IExpression original, IExpression replacement)
{
      code hier...
}

was gleich noch den netten Nebeneffekt hat, dass das VS.NET Intellisense zb. auch bei den Tags funktioniert, und es automatisch ein XML File extrahieren kann, mit dem man danach zb. per NDoc schöne MSDN like Referenzen generieren kann ... (hab ich zwar schon mal weiter oben erwähnt..)

V
842 Beiträge seit 2003
vor 20 Jahren

Ich weiß das es da summary gibt. Habe halt nur geschrieben wie das bei uns war. Ich hätte natürlich auch schreiben können: "Wir hätten summary wie folgt angewandt", weil summary ja nichts anderes ist, als ich geschrieben habe, wollte halt nur beschreiben wie wir Dokumentiert haben und in TP gibt es kein summary 😉

Code-Hacker

C
980 Beiträge seit 2003
vor 20 Jahren

Aber eine eigentliche Dokumentation, die über eine Beschreibung von diskreten (Klassen-) Schnittstellen und Implementationsdetails von irgendwelche Algorithmen hinausgeht habt ihr nie entworfen? So was wie Teil 3 in meinem obigen Post ... das ist ja v.a. das interessante (und entsprechend evtl. sehr aufwändig), zumindest für mich, bei Projekten die etwas über das trivial-OOP hinausgehen ...

V
842 Beiträge seit 2003
vor 20 Jahren

Nein. Wir hatten auch noch keine wirklich großen Programme, ich mein was soll man da mit Turbo Pascal schon machen. Das einzige was man damit sehr schön machen kann ist die Grundlagen der Programmierung zu erklären, weil diese Spache doch sehr einfach aufgebaut ist. Und es ist imho eine gute Voraussetzung andere Sprachen zu lernen. Ich habe jetzt neben TP seit dieser Schule (in der Real damals Comal!!!) in 4 anderen Programmierensprachen programmiert (Assembler natürlich ausgeschlossen) und ich hatte es immer sehr leicht vor allem bei Basic. Natürlich kann man das auch mit einer Hochsprache wie C++ machen, die aber imho schwerer zu erlernen ist und wenn man schon erfahrung hat mit dem Programmieren fällt es einfacher. Meine Meinung!
Naja und Dokumentation lernen wir ab dem 3 Semester richtig, weil wenn da ein Programm nicht Dokumentiert ist und selbst wenn es läuft wird es von den Dozenten nicht angenommen.
Aber der Teil 3 von dir sollte denke(!) ich nicht so schwer zu erlernen sein. Ich habe ne Klasse geschrieben für Laufschriften, hat allerdings nen scheiß namen (going), da könnte ich sowas mal mit einbringen. Achja, die Klasse ist für DOS, für Win werde ich aber auch nochmal eine scheiben, sobald ich bei Windows bin, habe noch einiges an Grundlagen zu bearbeiten.
Genug des gelabers....Doku soll jeder der nicht will das seine Programme und Klassen und was weiß ich nicht noch alles, von anderen gesehen werden, der sollte sie zumindest für sich so Dokumentieren, dass er sich schnell wieder zurecht findet. Jemand der natürlich im Team arbeitet muss sich an vorgegebene Teamrichtlinien/Standardrichtlinien halten ist klar!

Code-Hacker