Καλος ηλθες φιλε.

εχω κανει Ακριβως αυτο που θες για την ERP εφαρμογή μου το εχω παει ακομα παραπερα βεβαια, "ανοίγω" τα dll kai ψάχνω για κλαση με ονομα "plugin.vb" και εκτελω μεσα στη μεθοδο NEW  ενα αλλο function και φτιαχνω και δυναμικά Ribbon Toolbars για την εφαρμογή, δηλαδη κτίζω το UI.Αν για παράδειγμα εχω το αρχειο ERP_Customers.dll στο φακελο της εφαρμογης τοτε θα δω και το αναλογο κουμπι στο interface "Πελατες" και φερνω τα controls / forms που θελω για την ενοτητα αυτη.

Για να γινει αυτο ποιο σωστα καλο θα ηταν να εχεις ενα συγκεκριμένο ονομα αρχειων που θα ειναι plugins.dll και να μην σκασει ο κωδικας οταν θα βρησκει και "ασχετα" .dll

παραθετω το κωδικα μου γραφω σε vb.net

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 

Public Sub GetDLLS()

        'skip error for dlls that have similar name but are not plugins!
        'On Error Resume Next '''for testing
        'search into the application directory for specific DLL names and and later creat dynamically a new RibonPage in the main UI.
        Dim DLLlist As New List(Of String)
        Dim DLLpath As New IO.DirectoryInfo(My.Application.Info.DirectoryPath)
        Dim DLLfiles As FileInfo() = DLLpath.GetFiles("MyApplicationName_*.dll")
        For Each FileInfo In DLLfiles
            If Not DLLlist.Contains(FileInfo.FullName) Then
                DLLlist.Add(FileInfo.FullName)
                Dim A As Assembly = Assembly.LoadFrom(FileInfo.FullName)
                'search for the class named Plugin and execute the code from the method NEW
                Dim ClassName As String = Microsoft.VisualBasic.Left(FileInfo.Name, FileInfo.Name.Length - 4) & ".Plugin"
                Dim Plugin As Object = A.CreateInstance(ClassName, True)
                Dim T As Type = Plugin.GetType()
                T.GetMethod("New", BindingFlags.Public Or BindingFlags.Instance)
            End If
        Next

End Sub

Γενικά, αυτό που ζητάς δεν είναι και τόσο απλό πράγμα. Το δύσκολο δεν είναι τόσο στον μηχανισμό, όσο στο να σχεδιάσεις εκ των προτέρων κατά τέτοιο τρόπο την εφαρμογή σου ώστε το μελλοντικό plugin που θα γράψεις να μπορεί να έχει πρόσβαση στο functionality και στο state των data αυτού που τρέχει ως instance της εφαρμογής. Μιλάμε δηλαδή να σχεδιάσεις την εφαρμογή σου ώστε να βασίζεται σε ένα object model. Αν δεν το κάνεις αυτό, η επικοινωνία θα ειναι υποχρεωτικά πάντοτε από την εφαρμογή προς το plugin αλλά ποτέ από το plugin προς την εφαρμογή. Φαντάσου το κάπως έτσι: Θα ανοίγεις το dll, θα φτιάχνεις ένα instance από κάποιο object και θα καλείς κάποια μέθοδο. Αν δεν έχεις ξεχωρίσει το business logic της εφαρμογής σε ξεχωριστά objects ώστε να μπορείς να τα περάσεις στη μέθοδο που καλείς, τότε θα είναι περιορισμένα αυτά που θα μπορείς να κάνεις στο plugin.

Τώρα, ως προς τον μηχανισμό, αν ξεκινάς κάτι σήμερα, καλό θα είναι να κοιτάξεις αυτό http://www.codeplex.com/MEF Θα έρθει με το .NET Framework 4 ωστόσο δεν σε εμποδίζει τίποτα να το χρησιμοποιήσεις από τώρα.

Από την άλλη, αν θες να φτιάξεις κάτι δικό σου που να ελέγχεις τον κώδικα, ένα καλό ξεκίνημα είναι εδώ http://msdn.microsoft.com/en-us/library/ms972962.aspx (και η συνέχειά του - για να ξεφορτωθείς τα config αρχεία - εδώ http://weblogs.asp.net/rosherove/pages/Add-Plugins-to-Your-App-2_3A00_-Search-dynamically-for-plugins-without-Config-Files.aspx)

@pk

η εφαρμογή δεν σκάει ακριβώς γιατί ΔΕΝ βρίσκει "άσχετα" dll και οσα βρίσκει εχουν ολα την απαραίτητη class plugin και κάνουν αυτό που πρέπει να κάνουν χωρίς "κωδικοβολτες".. και αυτο πολύ απλά γιατί περιορίζω την "έρευνα" σε συγκεκριμένη ονομασία αρχείων name...*.dll.

Πιστεύω το να έψαχνα Ολα τα dll ενα-ενα AN "υλοποιεί κάποιο συγκεκριμένο interface " θα καθυστερούσα περισσότερο γιατί άλλο να κοιτάς σε 10 αρχεία και αλλο σε 30 εκ των οποίων μονο τα 10 θες.

αν τώρα ο τρόπος που λες δεν επιβαρύνει χρονικά την εφαρμογή κι αν εχεις καποια συγκεκριμένη διόρθωση πάνω στον συγκεκριμένο κώδικα να δείξεις - εξηγήσεις ευχαρίστως να το δω και να το υιοθετήσω αν μου κάνει και ετσι να "απαντήσεις" και στο ερώτημα του φίλου / topic .

Ευχαριστώ.

ΥΓ Τελος να πω κι εγω στον φιλο που ρωτα οτι ειναι οπως το λεει ο KelMan πρεπει η όλη φιλοσοφία σου να ειναι σωστή ώστε τα dll σου να κοιτανε προς την κοινή εφαρμογή και να ειναι ολα σωστα "κοματιασμενα" για να δενουν μεταξυ τους και να εναλλάσσονται πληροφορίες, για παράδειγμα ισως μέσω ενος κοινού αντικείμενου..

                                                                  |___________________>Customers object
APPLICATION------------->Common object----------|
                                                                  |___________________>Products object

(#^$@(*&^#(*&^$#(*&@ β μόλις έχασα τις 3 σελίδες που είχα γράψει!

Το θέμα του extensibility μίας εφαρμογής έχει πολλές παραμέτρους. Isolation μεταξύ host application και modules, ασφάλεια, versioning, ταχύτητα, εντοπισμός των addins, lifecycle (πότε φορτώνω-σκοτώνω το addin) κλπ. Γι αυτό και η απλοϊκή λύση του "το κάνω μόνος μου" μπορεί να οδηγήσει σε προβλήματα.

Πολύ επιγραμματικά, υπάρχουν 3 κατηγορίες λύσεων:

• Να χρησιμοποιήσεις κάποιο μηχανισμό addin όπως το MEF ή το System.AddIn (σύντομη περιγραφή εδώ, samples - tools εδώ) το οποίο παρέχεται από το .NET 3.5. Το MEF είναι ευκολότερο στη χρήση, το System.AddIn θέλει λίγο κώδικα με το χέρι αλλά έρχεται με το runtime.
  Είναι κατάλληλα όταν ξέρεις χονδρικά τί θα κάνει το addin σου, πχ. spell checking, νέος αλγόριθμος κλπ.
  Παρέχουν isolation μεταξύ εφαρμογής και addins, μηχανισμούς εντοπισμού και φορτώματος των addin, lifecycle management (πότε ανεβαίνει-πέφτει το addin), versioning (επικοινωνία διαφορετικών εκδόσεων εφαρμογής-addin μεταξύ τους).
  Κλασσική λύση, από τον καιρό του Photoshop 1.0 (νομίζω)
• Να χρησιμοποιήσεις κάποιο IoC container όπως τα Unity, Castle Windsor, Spring.NET. Δεν παρέχουν isolation κλπ αλλά γενικά είναι ευκολότερα στη χρήση. Και πάλι είναι κατάλληλα όταν η εφαρμογή σου ξέρει τί περιμένει να βρει στα addins. Συνήθως ορίζεις τα addin σε κάποιο config file, αλλά είναι εύκολο να φορτώσεις π.χ. όλα τα διαθέσιμα addin γράφοντας λίγο παραπάνω κώδικα.
  Κατάλληλο όταν θέλεις να φτιάξεις ένα απλό και γρήγορο μηχανισμό addin και είσαι σίγουρος ότι δεν θα χρειαστείς isolation κλπ.
• Να χρησιμοποιήσεις ένα extensibility framework όπως το Prism ή το XAF, τα οποία περικλείουν ολόκληρους τομείς functionality σε modules, με τις φόρμες, μενού, κώδικα που απαιτούν. Ουσιαστικά η εφαρμογή μετατρέπεται σε host των modules, κάτι που επιτρέπει να αναπτύξεις κάθε module ανεξάρτητα αλλά και να δημιουργήσεις διαφόρους συνδυασμούς modules
  Κατάλληλο για περίπλοκες εφαρμογές, π.χ. ERP, CRM και όπου χρειάζεται ή μπορεί να σπάσει η εφαρμογή σε ανεξάρτητα modules. Η μόδα του παρόντος και μέλλοντος σε αυτό τον τομέα.

Την περίπτωση να γράψεις με το χέρι τον κώδικα για να φορτώνεις τα dll, να ψάχνεις τα interfaces κλπ δεν θα τη συνιστούσα σε καμμία περίπτωση. Θα αντιμετωπίσεις προβλήματα τα οποία είναι ήδη λυμμένα, ενώ είναι σίγουρο ότι όσο ασχολείσαι π.χ. με το σκάσιμο του host, θα σου ξεφύγουν σημαντικά θέματα όπως το isolation και το performance. Σίγουρα έχει ενδιαφέρον να ασχοληθείς με αυτά τα θέματα σαν χόμπυ, όχι όμως όταν σε κυνηγούνε deadlines και αφεντικά.

Η επιλογή σου εξαρτάται από τις απαιτήσεις της εφαρμογής σου. Πριν επιλέξεις λύση θα πρέπει να σκεφτείς και να αναλύσεις (ή να μας πεις) τί απαιτήσεις θα έχει η εφαρμογή σου και μετά να δεις τί λύση ταιριάζει.

Υ.Γ. Να 'σαι καλά papageorge, είχε καιρό να ξεκινήσει τόσο ενδιαφέρον post στο DNZ. Κάτι μου λέει ότι αυτό το thread θα τραβήξει καιρό. Μάλιστα λέω να μεταφέρω τη συζήτηση στα θέματα αρχιτεκτονικής, καθώς το θέμα έχει βάθος, εύρος και είμαστε και σε φάση εξελίξεων (βλ. MEF)

Για σας,

Καταρχήν εγώ ευχαριστώ για τις εκτενείς απαντήσεις που δίνετε!

Το isolation Από ότι έχω καταλάβει έχει να κάνει με την απομόνωση του add-in από το κυρίως πρόγραμμα ώστε αυτό να μην μπορεί να το επιρεάσει (Δηλ θέμα security). Αυτό όμως δεν είναι υποκειμενικό; Δηλ το τι θα αφήσεις ένα add in να κάνει και τι όχι; Πως μπορεί να σου το προσφέρει αυτή τη δυνατότητα ένα έτοιμο framework;