Click here to Skip to main content
13,552,737 members
Rate this:
Please Sign up or sign in to vote.
Is it possible to use a plug-in architecture with a WCF service? I've read up a little on plug-in architecture and I am not completely sure if I am understanding its benefit that much. I have a simple WCF web service, that essentially streams in data and streams some data back; the data is xml. Someone has told me that me the behavior or functionality of the service could be modified or added on to by taking advantage of a plug-in architecture. Is that true? Is there any documentation/examples available online to point me in the right direction?
Posted 18-Jan-13 9:41am
SAKryukov 18-Jan-13 15:57pm
Generally, it's quite possible. I never knew any documentation, but I can just build such architecture, because this is one of the many things I do. It's hard to help you in a more concrete way, based on your very limited information.
iCanDivideByZero 18-Jan-13 16:06pm
What information could I provide to help. I mean, it sounds you are confirming what I heard. So by implementing a plugin architecture the behavior of the service can be changed/added on to then? That would be great!
SAKryukov 18-Jan-13 16:31pm
I have no idea what can you do. Isn't that obvious that you should know better?

Unfortunately, it can easily grow well out of the scope of this forum, which is called Quick Questions & Answers. And what you are asking about is rather pretty much a whole work at the technological architecture. I don't even have enough reason for a formal answer.

You see, even when you ask "added on to", I cannot see, add to — what, exactly? You might need to explain some ultimate goals of the whole product, the scope of expected changes in behavior of the service or communication, even the social and business model (like who is supposed to define changed behavior, implement plug-in, deploy it — where, what party should do it; and, importantly, why). I have a good number of past answers on plug-in architecture, but they are more general, not touching WCF aspects at all. And even they are pretty complex for understanding.

If you want, I could give you the links, so you would see what's involved from purely technological side. And then you could see what's involved and might see more clearly what about your product you might need to share... how about that?

iCanDivideByZero 18-Jan-13 16:45pm
Yes the links will be good enough, thanks. My apologies turning this into more than a quick Q&A session :)
SAKryukov 18-Jan-13 17:07pm
OK, done. What do you think? :-)
iCanDivideByZero 18-Jan-13 17:24pm
Sounds good! Now I got some reading to do lol. I will have to process this first before I can say I'll be able to make use of it. But at least I know for sure it's plausible now. Thanks!
SAKryukov 18-Jan-13 17:44pm
Well, if you see that it makes sense, please don't forget to accept my answer formally (green button).
In all cases, you follow-up questions on the topic will be quite welcome.

Good luck,

1 solution

Rate this: bad
Please Sign up or sign in to vote.

Solution 1

OK, as I promised, some links to my past answers:

Create WPF Application that uses Reloadable Plugins...[^],
AppDomain refuses to load an assembly[^],
code generating using CodeDom[^],
C# Reflection InvokeMember on existing instance[^],
Projects and DLL's: How to keep them managable?[^],
Gathering types from assemblies by it's string representation[^].

Sorry that the application fields mentioned above did not imply WCF (but might include it). I answered in so great detail to some of the questions referenced above mostly because the applications were much more certain than in your case.

Right now, I can add just a couple of considerations.

The most difficult technical issue with the plug-in architectures appears when you need to unload a plug-in. In some applications, it is never needed, so it makes things way simpler. Most likely, you will need it in your field, but I cannot be sure.

This is because unloading of an assembly is not allowed in .NET, by pretty obvious safety reasons. If you need to actually change some plug-ins during run time, you can only load a plug-in assembly in a separate Application Domain and later unload the whole domain. As the address spaces of different domains are perfectly isolated, it involved no danger of invocation of anything already unloaded. This is resolution is at the same time a difficulty, because the Application Domain can only communication via IPC (is that clear?). Fortunately, the AppDomain class provides highly simplified IPC facilities convenient and pretty easy for Application Domain communications.

And here is some good news related to WCF: WCF is already the IPC. It means that in proper architecture, you can introduce plug-in assembly and develop the mechanism of its use without adding additional complexity related to domain communications: they will communicate via WCF channels anyway. The same states for "classical" .NET remoting. (Some claim that "classical" .NET remoting should be considered obsolete, but I cannot agree with that, because it can provide better flexibility in more difficult scenarios than the typical ones.)

Does it make any sense for your? If you are getting to some ideas, your further questions are quite welcome.


This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month

Advertise | Privacy |
Web02 | 2.8.180515.1 | Last Updated 18 Jan 2013
Copyright © CodeProject, 1999-2018
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100