Große Anwendung splitten?

[semeier82]

Hallo zusammen,

ich habe die Aufgabe eine lokale Anwendung zu entwickeln.
Als Technologie wollte ich C# und WPF einsetzen.
Die "Hauptanwendung" wird ein Menü besitzen, welche viele, kleinere "Subprogramme" aufrufen wird.
Zum Beispiel eine Maske zur Belegerfassung, eine Art Kassenjournal usw.
Ich komme ca. auf 50 - 80 Anwendungen.
Würdet Ihr alle Anwendungen in einem Projekt hinterlegen oder würdet Ihr die vielen, kleinen Projekte in der Hauptanwendung als eine Art PlugIn zusammenführen?
In dem zweiten Fall würde ich doch für jede kleine Anwendung eine DLL erstellen lassen und diese in der Hauptanwendung als PlugIn einbinden. Oder?
Ich bin für jeden Tip oder sogar Code-Beispiele dankbar ...

Viele Grüße
Sven

[das-d]

sind die anderen Anwendungen auch alle .NET basiert? WEnn ja ist das erzeugen der Dll nicht unbedingt nötig weil auch eine exe eine Assembly ist die du einbinden kannst.

Wenn du es auf Pluginbasis machst hast du den riesen Vorteil dass du sehr modular bist und zum Beispiel deine Anwendung so aufzuziehen dass neue Anwendungen später einfach mit einbinden kannst ohne deine große Hauptanwendung neu kompilieren zu müssen. Allerdings solltest du dafür sorgen dass es eine definierte Schnittstelle gibt zu den anderen Programmen.

Wenn die andereen Programme keine .NET Programme sind dann weiß ich nicht wie du es am besten aufziehst aber da könnte dir die Suchfunktion weiterhelfen. DA ich glaube es wollte vor nicht allzulanger Zeit schon einmal jemand fremde Exe Dateien in seiner Form anzeigen.

[fanderlf]

Plugin funtioniert in etwa so:

[highlight=c#]
public interface IMainApplication
{
//Sachen die Deine Hauptanwendung zur Verfügung stellt
}

public interface IPlugIn
{
void Initialize(IMainApplication mainApplication);

//andere Sachen die jedes PlugIn zur Verfügung stellt
}
[/highlight]

Das PlugIn Assembly wird über Reflection geladen (z.B. aus einem PlugIn Ordner), dann schaust Du per Reflection ob in diesem Assembly eine Klasse ist, die das IPlugIn Interface implementiert.
Wenn ja, das Objekt instantiieren und Initialize aufrufen.

So in etwa könnte das aussehen:

[highlight=c#]
public void LoadPlugins(String assemblyFileName, IMainApplication mainApplication)
{
Assembly assembly = Assembly.LoadFrom(assemblyFileName);
Type[] loadedTypes = assembly.GetTypes();

var plugIns = loadedTypes.Where(x => x.GetInterfaces().Contains(typeof(IPlugIn)));

foreach (IPlugIn plugIn in plugIns)
plugIn.Initialize(mainApplication);
}
[/highlight]

[semeier82]

Vielen Dank für die schnelle Hilfe.
Die anderen Anwendungen werden ebenfalls neu entwickelt.
Von daher werden Sie genau so wie die "Hauptanwendung" in C# mit WPF aufgebaut. Für den Anwender soll es wie eine große Anwendung aussehen.

Habt ihr evtl. schon Erfahrungen mit der anschließenden Softwareverteilung oder mit Shadow Copying für die Plugins gesammelt?
Das währe das nächste was ich von vorn herein berücksichtigen muss ...

[fanderlf]

Da muss ich leider passen... müssen denn die Assemblies zur Laufzeit austauschbar sein? Ansonsten kann man sich shadow copying sparen, wenn ich das richtig verstanden habe.

An was genau denkst Du wenn Du von Softwareverteilung redest?

[semeier82]

Die Anwendung soll verteilt auf mehreren Rechnern laufen.
Wenn es jetzt eine neue Version geben wird, soll das Update automatisch beim Start der Anwendung gezogen werden.
Oder kann ich das schon mit dem Standard von .NET erledigen?
Geht das auch in Zusammenhang mit Plugins?
Während der Ausführung des Programms muss ich nicht umbedingt ein Update einspielen können ...

[fanderlf]

Also für Updates hab ich keine .NET Unterstützung gefunden. Wir haben eine drittanbieter Komponente hinzugekauft. Und zwar diese hier:

http://www.kineticjump.com/Update/default.aspx

Diese Software bietet unterstützt für alle möglichen Updates. Angefangen vom ganz einfachen FileCopy bei einer neuen Version (könnte man jetzt für jedes PlugIn einzeln erstellen oder nur für die Anwendung) über die Änderung von Registry Einträgen bis hin zum Absetzen von Datenbankkommandos und Ausführen von eigenem Code.

Kannst ja mal einen Blick drauf werfen

[Ralf Jansen]

Also für Updates hab ich keine .NET Unterstützung gefunden. Wir haben eine drittanbieter Komponente hinzugekauft. Und zwar diese hier:

http://www.kineticjump.com/Update/default.aspx

In .Net würde man zu ClickOnce greifen. Habt ihr das evaluiert und euch dann dagegen entschieden? Wenn ja fände ich es super wenn du berichten könntest warum. Habe ClickOnce selbst immer nur für kleinere Projekte benutzt/ausprobiert und wenn es da größere Schwierigkeiten in größeren Umgebungen gibt würde ich das gerne wissen.

[fanderlf]

Ich fand click once damals einfach nur konfus. Das war der hauptsächliche Grund warum wir uns dagegen entschieden haben.
Bietet denn ClickOnce einen richtigen Update mechnismus? Soweit ich das verstanden habe ist nur eine andere Form von Installer. Oder geht das in Richtung Java WebStart?

[Ralf Jansen]

Bietet denn ClickOnce einen richtigen Update mechnismus?

ClickOnce ist selbst aktualisierend(wenn man das will), heißt bei jedem Programmstart wird gegen die Installationsquelle verglichen und wenn dort etwas neueres gefunden wird automatisch aktualisiert.

[semeier82]

Super!
Vielen Dank ...
Werde mir mal ein kleines Beispiel für eine ClickOnce Anwendung basteln.
Kann ich als Installationsquelle einen Webserver oder Ähnliches hinterlegen?
Das Update soll, wenn möglich, übers Internet gezogen werden.

[Ralf Jansen]

Kann ich als Installationsquelle einen Webserver oder Ähnliches hinterlegen?

Schon der erste Satz der Doku verrät es