Ok...I'm back with the final post about extension/plug-in loading in Silverlight. Well, at least I think it is the last as I have tried all obvious ways. I have previously showed how to it manually here and then how to do it "automatically" using MEF here. Both these have some upsides. The custom solution is tiny from a download perspective and offers a lot of control. MEF on the other hand automates a few pieces of the solution, still offering a lot of manual control. The download size does however grow a lot compared to the benefits gained. So, so far, I would say that the custom way is the winner. At least as long as the requirements are as simple as they are in this case...
This last post is all about doing it according to the Composite Application Guidance (CAG). CAG is a set of guidelines and patterns for building composite applications in WPF and Silverlight. The CAG is implemented by using the Composite Application Library or PRISM framework. CAG talks about how to do it, while CAL consists of assemblies helping the developer to actually do it. At least that is the way that I have understood it.
More...
In my previous post I wrote a demo application that used a custom implementation to load plug-ins from the server and place them in a shell. This implementation was very specific and limited in its functionality. It did however do what I needed for the simple task at hand. This post is all about how we can do the same thing using the Managed Extensibility Framework (MEF). MEF is of course a lot more flexible and powerful than my simple implementation, and then what I am about to use it for. But I will build the same application using MEF anyway, and show you how it works in comparison to the custom solution.
More...
Building an application based on discrete pieces (plug-ins) isn’t a new thing. It has been around for ages. Loads of applications support a plug-in model. So, obviously you can do the same using Silverlight. There are even a lot of different ways of doing it. They all have benefits and cool tricks up their sleeve, but they also come with bad things as well. I have decided to take a look at three of the more common ways of handling this whole thing. The first attempt I’m going to show is using the good old “I’ll do it myself” approach. I want to start out in this end, and then compare two other common approaches to the custom built one. This way I feel that you can thorough comparison.
The other two approaches I will show are Managed Extensibility Framework, commonly known as MEF, and Composite Application Guidance, also known as CAG or Prism. And to be honest, I don’t know if the third option should be CAG/Prism or CAL (Composite Application Library), but who cares. You know what I mean…
More...
I just remembered that I just HAVE to recommend this great plug-in for Windows Live Writer. It is the plug-in I use to add code snippets to my blog posts. There are a few things design wise I would probably want to be able to change. For example being able to turn off the scrollbars and show all the code formatted straight up in a nice way. But except those minor things, it is a great plug-in. You can find more info about it here and download it here.
If you know any REALLY good plug-ins for code blogging, don’t hesitate adding a comment about it. I’d love to find more goodies…I just don’t have time to go looking for them…
24. November 2008
ZeroKoll
EPiServer
When creating a GUI-plugin you are basically either creating a usercontrol (ascx) or a webform (aspx). The problem with this is that when you deploy your plugin you have to deploy both an assembly and a second file. The location of the second file is of utmost importance since it is defined in the GuiPlugInAttribute's Url property. Is this a problem? Not in most cases, but once in a while it is. Can it be solved? Of course...
More...