Hallo zusammen,

die Aufgabe scheint etwas komplexer als gedacht ...

Ich möchte mit einer Truppe von Entwicklern an einem größeren Projekt arbeiten. Meine Vorstellung ist, dass ich einen 'Navigator' programmiere, der Plugin DLLs lädt, die jeweils einen Funktionsbereich abdecken. Im Plugin ist die zugeordnete Form, und der Code (z.B. Stammdatenpflege -> User, das Plugin und der Entwickler kümmern sich nur um User-Pflege).

Die Form möchte ich im übergeordneten Navigator 'reinziehen' Ich hab das innerhalb eines Projektes mit Formxyz.Topmost=false und Navigator.Controls.Add(Formxyz) auch bereits hinbekommen. So stelle ich mir das auch vor, nur ...

Ich möchte die Form aus der Plugin.DLL in den Navigator bekommen und nicht eine Form aus dem Navigator Projekt selbst.

Ziel ist es, dass viele kleine Plugins parallel entwickelt werden können, die dann im Zielsystem wie eine Anwendung aussehen. Und natürlich dass meine Entwickler 'austauschbar' an verschiedenen Modulen arbeiten können.

Übrigens:

Die Plugin Thread habe ich mir bereits angesehen und auch fleißig ge-googled - bei mir kommt aber immer ein RTE, also funzt nicht wirklich...

Kann mir da jemand Unterstützung geben?

Vielen Dank im Voraus

Ole Grossklaus

... mit einer Truppe von Entwicklern...

Mit einer Truppe ... ham' die alle keine Ahnung oder ... ?

Und was genau nun die Frage hier ist die beantwortet werden soll, ist mir auch nicht ganz klar. Sollen wir das komplette Programm für dich machen oder wie oder was? Denn dann poste das bitte im Marktplatz-Unterforum





link_275

warum müssen das plugins sein?

wäre doch bestimmt einfacher, wenn deine entwickler je ein projekt machen, und die navigator-solution kompiliert das halt zusammen.

soweit ich weiß ist es nicht möglich verweise über code zu erstellen, da das .net immer eine interopt erstellt

wenn ich falsch liege verbessere mich bitte einer

link_275 schrieb:

Mit einer Truppe ... ham' die alle keine Ahnung oder ... ?

Wenn ich das so genau wüßte ... Die Truppe muß erst noch zusamenngestellt werden. Die Architektur muß vorher stehen (sozusagen Machbarkeitsstudie). Im Moment bin ich noch Einzelkämpfer...



Warum Plugins?

Weil ich denke, dass dann die Entwickler am unabhängigsten voneinander arbeiten können und man im Zielsystem eben NICHT immer ein komplettes Deploy machen muss sondern nur einzelne Plugins austauscht. /zu naive Vorstellung???)

Ich suche natürlich keine komplette Lösung sondern Ideen und Anregungen, wie das am Besten zu realisieren ist.

Zum Umfang:

Wir hantieren im Moment mit ca 10 eigenen Anwendungen, alle in anderer Technik. Delphi, Access, ASP, VB6 VB.NET usw usw. Alle sehen unterschiedlich aus, weil jeder macht, was er will/kann und zudem noch externer Dienstleister ist (so kleine ahnungslose Bastler). Ich soll das stoppen und hier Struktur reinbekommen. Alles soll VB.NET2010 und .NET4 und einheitlich aussehen. Ich möchte daher alles modular haben und möglichst handlich, wenn wir hier beginnen (wir redun über locker mal 500-600 Funktionsbereiche über ca 10 Anwendungen. Ich will nur einmal z.B. Benutzerpflege als Plugin bauen (lassen) und das dann in allen 10 Anwendungen nutzen können indem ich das Plugin deploy. Eine Anwendung hat eine etwas andere Benutzersteuerung, daher dort ein anderes/ähnliches Plugin deployen.

Ich suche nach Ideen und Lösungsansätzen, dass wir hier in der Entwicklung nicht damit untergehen.

soweit ich weiß ist es nicht möglich verweise über code zu erstellen, da das .net immer eine interopt erstellt

->Passiert hier :P:

Thema Reflection...Aber ein Plugin System mit einem gemeinsamen Interface ist ja wohl Intelligenter, wenn dieses Interface einem genügend Zugriff auf das Hauptprogramm erlaubt, das müsstest du halt entsprechend programmieren...

Wir hantieren im Moment mit ca 10 eigenen Anwendungen, alle in anderer Technik. Delphi, Access, ASP, VB6 VB.NET usw usw.

und soweit ich weiß kommt vb auch nur mit .Net dlls klar das heist delphi und vb6 fällt weg

und wie immer wenn ich falsch liege bitte verbesser mich einer

CodeVerwaltungs-Infrastruktur steht, und Unit-Tests setzt ihr auch ein?

mitte Pluggerei binnich immernoch skeptisch: muß man da nicht für jeden Käse ein Interface definieren? Und dann immer von System.Object aufs Interface casten (womit man im Grunde das Prinzip der TypÜberprüfung aushebelt)?

Genau: Wir wollen alle Anwendungen portieren nach VB.NET 2010 und .NET4 (kein Delphi, Kein Access) alles auf einer Basis

mitte Pluggerei binnich immernoch skeptisch: muß man da nicht für jeden Käse ein Interface definieren? Und dann immer von System.Object aufs Interface casten (womit man im Grunde das Prinzip der TypÜberprüfung aushebelt)?

Es reicht ein Interface, alles andere währe ja Sinnlos...Über dieses sollte es halt möglich sein auf die GUI und evtl. Prozeduren des Hauptprogramms zuzugreifen, mehr ist gar nicht nötig, denn der Rest kann dann im Plugin selbst jeweils geschrieben werden...Ein Cast aufs Interface ist ja klar, so funktioniert das nunmal, da man den Typen darüber ja nicht verwenden kann wenn man keinen Verweis hat(außer mit Reflection)...

und soweit ich weiß kommt vb auch nur mit .Net dlls klar das heist delphi und vb6 fällt weg

Per API Deklerationen ist das auch anders möglich, ist aber meiner Meinung nach unschön und verbraucht sehr viel Platz+dlls...
Jeweils eine HauptDll + Wrapper-Plugin wenn man es über das Plugin System machen will...

damit ist aber klar, dass die plugins nicht untereinander kommunizieren können?

Da könnte man ebenfalls etwas ins Interface einprogrammieren, doch spezielle Dinge der Kommunikation, die nur auf bestimmte Plugins zutreffen sind wiederum schon schwieriger und wären wohl am geschicktesten wiederum per Reflection lösbar^^

ErfinderDesRades schrieb:

damit ist aber klar, dass die plugins nicht untereinander kommunizieren können?

kommt drauf an, wie man das baut - und ob die das überhaupt müssen ...

ErfinderDesRades schrieb:

CodeVerwaltungs-Infrastruktur steht, und Unit-Tests setzt ihr auch ein?

das soll alles noch aufgebaut werden.

Bin übrigens einen Schritt weiter. Ein eigenständiges Projekt hat Public Class frmMain, somit kann ich das in den Navigator mit Implements reinholen und mit New Form instanzieren. Dann mit TopLevel = false und Navigator.Panel.Controls.add(ChildForm-aus anderem Projekt) tatsächlich ins übergeordnete Projekt reinholen. Ich bin nahe dran an dem, wie ich mir das vorstelle.

du willst ein Form auf ein Panel adden? Dafür sind aber doch UserControls da.

ErfinderDesRades schrieb:

du willst ein Form auf ein Panel adden? Dafür sind aber doch UserControls da.

klar will ich das - und es funzt schon ein wenig. Um genau zu sein IN ein Panel rein (Panel ist der Container der Form). Warum extra noch Usercontrols bauen, wenn es auch mit Boardmitteln geht. Ein UserControl ist auch nix anderes (technisch betrachtet) als ein BuildInControl, oder??

Ole.Grossklaus schrieb:

klar will ich das -

eine komische Mode ist das - bin ja noch nicht lang hier im Forum unterwegs, aber finde ich schon auffallend.
Usercontrol und Form sind in der Tat sehr ähnlich (vlt meinst du das mit "BuildInControl"?).
Und der Unterschied ist genau der, dass Form frei herumfliegen soll, und UserControl gehört in ein Form eingebettet.
Deswegen hat Form einen Titelbalken, und kann man verschieben, minimieren, vergrößern und wegklicken - und UserControl nicht.

Benutze das Managed Extension Framework (MEF) oder das Managed Addin Framework (MAF) von .NET.
Eine eigene Plugin-Infrastruktur ist heute in den wenigsten .NET-Programmen noch sinnvoll oder gar eine gute Wahl.

ErfinderDesRades schrieb:

Usercontrol und Form sind in der Tat sehr ähnlich

und genau deswegen nutze ich die Forms. Nehm ihr den Rahmen und die Titelleiste weg, dann verhällt sie sich wie ein UserControl. Warum etwas selbst programmieren, wenn es bereits FERTIG vorliegt - mit Properties, Events usw usw. Und eine Form kann mehr als nur frei auf dem Desktop 'herumfliegen' Sie kann eben auch ihren 'Parent' ändern, also sich vom Desktop-Container in einen anderen Container bewegen (hier das Panel).

Aber nun habe ich dazu genug geschrieben - meine Frau wartet bereits und ich krieg nur wieder einen auf den Deckel. Kennt ihr das auch???. Bis Morgen.

Das geht genauso mit jedem anderen Control...
Wenn du den Rahmen des Formulars nicht benötigst ist es wirklich intelligenter ein UserControl zu verwenden...

Ole.Grossklaus schrieb:

Warum etwas selbst programmieren, wenn es bereits FERTIG vorliegt -

hä?
UserControl liegt genau so (un)fertig vor wie Form. Sind ja beide nicht von haus aus fertig, sondern man gestaltetse im Designer.

Als Projektleiter fürn fettes Programmpaket sollte man aber so Basics draufhaben, und gucken, nach Standards zu proggen. Ansonsten verbraten Folgegenerationen von ProgrammPflegern immer Stunden mit der Frage "Wieso zum Kuckuck hatterhier kein UserControl, sondern macht ein Form aufs Panel??"