Thanks - that's very helpful. Maybe there are benefits with WPF that don't make sense to me because I haven't really started using that yet. However, it still sounds to me like most of the benefits of System.AddIn can be accomplished with the strategy pattern. I have multiple apps that use the strategy pattern and I can extend them to my hearts content without re-compiling by just adding a new provider to the app.config and supplying the necessary DLLs. It is also a heck of a LOT easier to implement than the System.AddIn model...
It sounds like most of the benefits of System.AddIn stem from the fact that add-ins run in separate app domains.
So crashes in one add-in won't take down the main app.
Add-ins can be swapped without having to restart the app and versioned differently.
Different addins can be loaded with different security configurations.
Sandboxing is possible.
These are all good benefits. But in most small to medium sized apps, the AddIn model still feels like a LOT of overhead. I mean - unless one ore more of the reasons listed above is really critical to your app - it still doesn't sound worthwhile.
Any other suggestions about other benefits that will compensate for the extra complexity? Thanks.
Main Topics
Browse All Topics





by: ChaosianPosted on 2008-08-20 at 10:15:42ID: 22271877
http://msmvps.com/blogs/ka thleen/arc hive/2008/ 01/14/syst em- addin-s cenarios.a spx msmvps.com /blogs/kat hleen/arch ive/2008/0 1/03/why-y ou- care-ab out-system -addin.asp x
http://
The biggest difference I've gleaned is that AddIn allows *other developers* to extend your code and have it play as if it's a native part of your application.
The provider model requires access to your source code to plug in.