Architektura podobna do wtyczki in.NET

Polecam zajrzeć do MEF . Jest to nowy sposób robienia wtyczek w .NET. jest to zalecany sposób robienia nowych dodatków na przykład dla VS2010. Sam go nie używałem, ale to, co sprawdziłem, wygląda świetnie. Dodam to jako odpowiedź na pytanie innych:)

Jest dobra książka na temat budowania tego, czego szukasz: rozcinanie aplikacji C#: Inside SharpDevelop. Oto link: http://www.icsharpcode.net/OpenSource/SD/InsideSharpDevelop.aspx

Aplikacja SharpDevelop jest w pełni oparta na wtyczkach, a książka opowiada o tym, jak ją zbudowali, pułapkach, z którymi się zmierzyli i jak ją pokonali. Książka jest swobodnie dostępna na stronie, lub można ją kupić.

Kiedyś zrobiłem to używając tego przykładu . Podobało mi się, ale to było kilka lat temu, myślę, że teraz mogą być lepsze rozwiązania. O ile pamiętam podstawową ideą było to, że w twoim programie jest klasa abstrakcyjna, a twoje wtyczki dziedziczą tę klasę i są kompilowane jako biblioteki DLL... lub coś podobnego za pomocą interfejsów. W każdym razie, to podejście działało świetnie dla mnie. Później dodałem filesystemwatcher, aby mógł załadować te wtyczki DLL, gdy jest uruchomiony.

Aby załadować Assembly

Aby uzyskać typy, montaż eksponuje

O dwóch konkretnych problemach, które ujawniłeś:

1) nie jestem pewien, co próbujesz osiągnąć, ale domyślam się, że chcesz mieć leniwe inicjowanie funkcji, a może leniwe Ładowanie dodatków. Jeśli taki jest cel, to co proponujesz może zadziałać. Więc może działać tak:

• wtyczka y dostarcza listę funkcji, z których musi korzystać (można to zrobić na przykład poprzez konkretną implementację interfejsu lub poprzez manifest xml).
• The X add-in implementuje API, które umożliwia inicjalizację funkcji za pomocą metody Initialize (featureId) .
• aplikacja hosta pobiera listę funkcji wymaganą przez Y, ładuje / inicjalizuje wtyczkę X i wywołuje Initialize dla każdej funkcji.
• aplikacja hosta zapewnia również metodę GetFeature () , której Y może użyć, aby uzyskać odniesienie do obiektu 'feature', który byłby zaimplementowany w X.

Jeśli jednak wtyczka Y ma bezpośredni dostęp do API X, Myślę, że nie jest konieczne posiadanie całej tej infrastruktury do rejestrowania funkcji. Y może po prostu uzyskać dostęp do funkcji X bezpośrednio za pomocą X API, A Y zajmie się leniwą inicjalizacją każdej funkcji, gdy jest to wymagane. Na przykład, Y może po prostu wywołać SomeXFeature.DoSomething (), a implementacja tej klasy zainicjalizowałaby tę funkcję przy pierwszym użyciu.

2) jeśli API zestawu ulegnie zmianie, każdy zestaw może ulec awarii. Wtyczki są tylko złożeniami, które zależą na innych zgromadzeniach, więc będą one również złamać. Oto kilka rzeczy, które możesz zrobić, aby złagodzić ten problem.

• Przypisz numer wersji do każdej wtyczki. To może być tylko Wersja montażowa.
• podczas ładowania wtyczki upewnij się, że wszystkie zależności mogą być prawidłowo spełnione (tzn. wszystkie wtyczki, od których zależy, muszą być obecne i mieć wymaganą wersję). Odmówić załadowania wtyczki, jeśli zależności nie mogą być spełnione.
• zaimplementuj narzędzie do zarządzania wtyczkami, aby być używany do wszystkich operacji instalacji/deinstalacji wtyczki. Menedżer może sprawdzać zależności i zgłaszać błędy podczas próby instalacji wtyczek z niezaspokojonymi zależnościami lub podczas próby odinstalowania wtyczki, od której zależą inne wtyczki.

Podobne rozwiązania są stosowane przez Mono.Addins framework. W Mono.Addins, każdy dodatek ma numer wersji i listę dodatków/wersji, od których zależy. Podczas ładowania dodatku silnik dodatku zapewnia, że wszystkie zależne dodatki z poprawnymi wersjami są również ładowane. Zapewnia również API i narzędzie wiersza poleceń do zarządzania instalacją dodatków.