"object reference to set to an instance of an object" in zusammenhang mit static und dll

[DaEgi]

hallo ich hab ein kleines problemchen bei dem ich mal eure hilfe braeuchte.
bin noch nicht besonders vertraut mit OOP, deswegen hat sich bei mir wohl ein logikfehler, den ich nicht begreife, eingeschlichen.

die situation sieht folgendermasen aus:

ich hab drei files:
plugin.dll
process.dll
loader.exe

mit loader.exe starte ich den gesamten ablauf.
process.dll hab ich als notloesung eingefuehrt. dort soll eigentl. der process verwaltet werden. d.h. dort will ich die start und end methode fuer meinen process reinhauen.
plugin.dll wird automatisch von einem programm gestartet, dort ist der wesentliche ablauf fuer das programm.

als hintergrund info: ich wollte eigentl. nur erreichen dass ich alles mit einem externen programm starten kann "loader.exe", allerdings das plugin das programm, wenn alles fertig ist, wieder beendet. und da ich mir dachte, dass der loader und das plugin ja aufs selbe objekt zugreifen, lager ich es in einer dritten datei aus. wenn ein solcher aufbau bloed ist .. bitte bescheid geben *G*
ich bin fuer verbesserungsvorschlaege offen.

der code:

class loader{
  static void Main(string[] args){
    myNamespace.myProcess.start();
  }
}

public class myProcess{
  static System.Diagnostics.Process cProcess;
  static String processPath = @"c:\whereever\";

  public static void start(){
    cProcess=System.Diagnostics.Process.Start(processPath + "programm.exe");
  }

  public static void end() {
    cProcess.CloseMainWindow();
    cProcess.Close();
}

public class plugin{
  blablabla
  blablabla
  myNameSpace.myProcess.end();
}

das problem:
"object reference to set to an instance of an object"
und zwar im plugin. hab ich irgendwas falsch verstanden ? %(
schliesslich fuehrt das plugin .end() aus ... welche wiederum in meiner dll cProcess.Close() ausfuehrt. da ich ja den loader benutzt habe, muesste cProcess ja aufs objekt von "System.Diagnostics.Process.Start(processPath + "programm.exe");" zeigen und somit in ordnung sein?!?!

hab ich zuviel mit static rumgespielt?

fuer hilfe waer ich sehr dankbar

[DaEgi]

ich hab das ganze jetzt vereinfacht, als ich gemerkt hab dass ich keine seperate dll brauche sondern auch direkt die exe als referenz einbinden kann.
das problem ist allerdings das gleiche geblieben

loader.exe

using allesmoegliche;

public class loader{
  static Process cProcess;

  static void Main(string[] args){
    startApplication();
  }

  public static void startApplication() {
    cProcess = Process.Start(@"myProgram.exe");
  }

  public static void closeApplication() {
    cProcess.CloseMainWindow();
    cProcess.Close();
  }
}

plugin.dll

<loader.exe wird als referenz eingebunden>
blabla
blabla
myNamespace.loader.closeApplication();

... object reference not set to an instance of an object ...

[simon.gysi]

Du solltest so ein Plugin Mechanismus auf eine andere Art impl.
(Assembly's dynamisch in den Host laden.)

So wie Du das versuchst, erzeugst Du für das Plugin einen neuen Process.
Der Datenaustausch (auch Methodenaufrufe) können processübergreifend nicht über statische Variablen realisiert werden.

[DaEgi]

uff ... danke *G*
hab noch keine ahnung von assemblys .. aber naja .. wofuer sind tutorials da ^^
ich geb bescheid wenn ich weitergekommen bin.

[loks]

DaEgi schrieb:

hab noch keine ahnung von assemblys ..

Was glaubst Du denn sind DLLs? Es ist grundsätzlich immer hilfreich wenn man sich erst einmal mit der Theorie auseinandersetzt.

[ssss]

Denkbar wäre eine einfache, eigene Lösung bei der mit Hilfe von Reflection alle DLL Dateien aus einem Plugin-Verzeichnis geladen werden und nach Klassen gesucht wird, die eine bestimmte Schnittstelle implementieren. Einen englischen Artikel dazu gibt es hier:
http://www.codeproject.com/KB/cs/pluginsincsharp.aspx

[DaEgi]

@loks: dynamic link libraries?
jedenfalls hab ich mich ein wenig mit der theorie auseinander gesetzt, was mich der loesung nicht naeher gebracht hat.

@ssss: danke fuer das beispiel, allerdings blicke ich es noch nicht ganz und es er scheint mir (vielleicht auch nur weil ich es nicht verstehe) als viel zu aufwendig fuer mein problem.

ich hab mir jetzt ein workaround geschaffen indem ich einfach aufgut glueck meinen loader solange offen lasse und in sleep schicke, dass ich davon ausgehen kann dass der vorgang im plugin vollstaendig durchlaufen wurde. anschliessend beendet der loader den ganzen process auch wieder.

mit der loesung bin ich zwar sehr unzufrieden weil sie recht unsicher ist,
aber fuers erste muss es wohl oder uebel reichen.

falls jemand nicht die muehe scheut mir eine andere "einfachere loesung" zu linken oder selbst zu schreiben, ich waere sehr dankbar.

ich will ja nur das fileA einen process oeffnet und fileB diesen process wieder schliesst.

[simon.gysi]

ich will ja nur das fileA einen process oeffnet und fileB diesen process wieder schliesst.

1. Starten des fileB im fileA mit System::Diagnostics::Process, genau wie Du es gemacht hast.
2. Beenden des processes von fileB muss im fileB selbst geschehen. Das Program (fileB) soll sich selbst beendet, nachdem es den "Job" erledigt hat.
Dazu gibt es mehrere Möglichkeiten:
- Falls fileB ein Consolen Programm ist: return aus dem Main.
- Falls fileB ein Window Programm ist: die Main Form schliessen, durch die Close() Methode der Form.

Falls Du zusätzlich in fileA noch warten willst mit beenden, kannst Du darauf warten, bis der Process von fileB beendet ist. (Du kannst auch den return Wert des Processes auswerten.)

Darf ich fragen was der Grund für deine Bemühungen ist?
Ev. gibts einfachere Lösungen zu deinem Problem, z.B. Batch- Dateien.

Gruss Simon

[DaEgi]

Dazu gibt es mehrere Möglichkeiten:
- Falls fileB ein Consolen Programm ist: return aus dem Main.
- Falls fileB ein Window Programm ist: die Main Form schliessen, durch die Close() Methode der Form.

das ist halt das problem ... es ist weder noch. fileB ist ein plugin inform einer .dll die von dem programm automatisch ausgefuehrt wird, welches ich starte.
das programm ist closedSource, nennt sich district10, laesst sich ueber eine mitgegebene API (die zudem nicht anstaendig dokumentiert ist) steuern und bietet eigentl. eine eigene "quit"-methode an. bloed nur wenn diese nicht sauber funktioniert. diese beendet zwar die application, der process bleibt allerdings offen.