Many popular applications such as Wordpress, WHMCS and the majority of PHP forums allow plugins to hook into core application events (such as registration, logging in, create post etc.) by simply specifying a function with a particular name.
I understand that these applications are not pre compiled, but is it possible to do something of the sort with C#? I've looked into event handlers, but it seems that you can only accomplish this if the plugin has the ability to instantiate the class that we want to hook into (or at least thats what searching has lead me to believe)
Ideally, these hooks would be into business layer class events/methods and can be hooked into by multiple objects, so it would function in either WinForms or ASP.NET MVC.
Given Alex's answer, this should be useful:
System.AddIn Tools and Samples
http://clraddins.codeplex.com/
If you design your application for extensibility, this is easy. The Managed Extensibility Framework is designed for exactly this sort of scenario, and makes it very easy.
It will be included as part of the core framework in .NET 4, but is downloadable now for use in 3.5.
There is an AddIn framework shipping with .NET 3.5. The framework provides very powerful mechanisms to expose interfaces by a host application and to manage, dynamically load-unload addins etc.
Why the core concept that comes up to my mind first, is Dependency Injection? I haven't ever played with a plug-in system in any app of mine. Does DI could help anyhow with that??
Specifics on our senerio would be helpful, but generally, You may want to explore the provider psttern.
There are 3 components:
- An abstraction of a piece of functionality, (Interface/baseClass)
- A Factory method that looks to config to determine what type of Class to create
- [your] Custom Class which extends/implements the abstraction. for example, a Membership provider class that hits a custom dasta source for user info.
This is very useful when switching out logic. If you want to create an app with swappble UI components, it is another story.
There is support for this in ASP.NET, starting with 2.0.
More info on the provider:
http://msdn.microsoft.com/en-us/library/ms972319.aspx
Related
I am working on a server side application which should dynamically load modules at startup based on whether or not they exist as assemblies. I've done something similar before, but this time it's production code and I want to use frameworks for modularization and instantization (using IoC containers). I initially found Microsoft's Prism (with Unity) to be a suitable framework to do this, but I am growing concerned as I am implementing initialization and bootstrapping. The server will not have it's own GUI and will presumably run as a windows service at a later time. (I'm developing it as a simple console application in the meantime.) Various clients (roughly one client application per module) will be developed to interact with the server over WCF.
Should I even be using Prism for such an application, since it seems so geared towards GUI-enabled applications? I stopped coding when using the base class Microsoft.Practices.Prism.UnityExtensions.UnityBootstrapper which requires implementation of a CreateShell() method. I kind of expected it to be named something like Run() or something similar. I don't really have a shell, or at least a GUI shell. Am I reading to much into this, and does it make sense to use Prism without worrying about it having potentially redundant GUI functionality? Am I using the right tool for the job?
I think you already know the answer. Prism is for client applications. Even if you get this working in your server environment, there will be a lot of the framework that's just in the way. You do want to use an IoC container and you're already using Unity for this (Prism by default uses Unity). My advice, ditch Prism and start wiring everyting using Unity. Dynamically loading assemblies is super easy. You don't need a bloated framework just for loading assemblies.
As stated in Steven's answer, Prism is intended for client applications. Unity is a good choice of dependency injection container, however I believe for your situation you would likely be much better off making use of either the Managed Extensibility Framework (MEF) or the Managed Addin framework (MAF).
Unity is primarily is used when the type mappings are known at compile time, before version 2.1, there was no out of the box support for dynamic type registrations.
The Managed Extensibility Framework is ideal at dynamically discovering types for dependency injection. See here for the amount of options it provides for dynamically loading types from runtime assemblies.
The Managed Addin Framework is a part of the .NET framework since .NET 3.5, one of it's largest features is the assembly isolation, assemblies can be loaded into separate app domains and even processes and then still be used. This is great for third party addins, if they are buggy and crash, they will not bring your application down with them.
Can you please provide me with some tips/guidelines when architecting, designing and implementing a .net framework application, with the requirements given below:
It will be an analytical tool which will retrieve data from files, sql databases and may be cubes. So data layer should be able to handle that. The middleware should be totally independent of the other layers so probably need an IoC container (which one would you recommend)
It will be deployed on the local intranet
The front layer might be WPF application or Silverlight in future (for now, I am concentrating on Silverlight but the point is that it will change)
It should be easy to customise and improve it in the future without changing much of the code as the framework will be deployed for many clients
I need a way to store the configuration information, which will be picked up by the application on application load events to set its feel and look.
I have two months to implement it and looking for as many tips as possible.
SoC for a start
break your application into several assemblies that use IoC (interfaces + implementations):
application model assembly - all other assemblies will reference this one because these classes will be used for inter-communication - they will mostly be just POCOs
presentation assembly - references app model and business services - this one is either WPF or Silverlight in any case use MVVM to make your testing life easier
business services assembly - references app model and data repositories assembly
data repositories - these define repositories that actually get data from the stores
Then I'd create three additional ones:
file data providers
database providers
cube providers
Data repositories would reference all three and use them to provide necessary data.
If configuration becomes very complex with a lot of functionality then you should put it in a separate assembly as well and reference it by business services assembly.
Which MVVM library to use
Since you mentioned time I suppose you'll have hard time catching your deadline. When using MVVM (which I suggested to use) I also suggest you don't use a full blown PRISM (a.k.a. Composite Application Guidance from P&P) but rather go with MVVM Light Toolkit. It will take you less time to get on the bandwagon.
Code generation
In places where appropriate I suggest you use T4 to its full potential. I use it to import stored procedure calls to avoid using magic strings when calling stored procedures (and using their parameters). Check my blog post about it as well.
DAL technology/library
Don't write your own data access code using things like SqlConnection/SqlConnection functionality. There're many data access layer libraries/technologies today that you can use and not reinvent the wheel. If you know nHibernate, then use that. If you know EF, then use that. If you know anything else, use that. Anything that will provide/generate as much code for you as possible that is already tested and debugged.
So it all boils down to:
DRY + YAGNI
a.k.a. Don't repeat yourself and You ain't gonna need it = don't over-engineer you code.
Agile developers are supposed to be lazy
They should develop just as much as it's needed and no more! TDD implicitly provides this process by the red => green => refactor steps.
I would recommend using MVVM and Test Driven Development. The MVVM will give you good separation between the front and middleware, and the TDD will help control the chaos that comes with any nontrivial app development.
Have a look at the Composite Application Guidance from Microsoft's Patterns and Practices group, it may not match what you are doing exactly but will give you some good ideas.
From an architectural standpoint, I highly recommend taking a look at the Microsoft Application Architecture Guide. Since you are already using the Microsoft technology stack, I would consider using Microsoft Unity for IoC. You indicated that your presentation layer might use WPF or Silverlight, so take a look at using Windows Communication Foundation, as you will be somewhat constrained in Silverlight when it comes to communication with your data layer.
What is the simplest way of converting my .NET C# windows forms app to a silverlight app?
Thanks!
You will need to re-write all GUI completely.
If you used any pattern separating business logic and data model from its presentation (MVC, MVP) it will be easier to port user interaction. If you used any database access layers or framework, they can most certainly be reused in Silverlight project. However, if your application logic is defined in form event handlers and data access is performed from within them, chances are high that you'll have to write a new application.
Also note that you can't use third-party libraries compiled for standard .NET Framework in Silverlight. You'll either need to recompile them, provided that you have the sources, or look for a specific Silverlight version of the binaries.
Standard .NET Framework libraries can easily be accessed, however there are some exceptions to the rule. For example, obviously, there is not System.Windows.Forms in Silverlight subset of .NET Framework.
To give you a better answer, I need more details: what kind of application are you considering to port, what libraries does it use, whether business logic is separated from presentation logic, etc.
Regarding the UI there is a Windows Forms to XAML Converter that may help a bit.
I’m writing an ASP.NET MVC 2 application where developers could extend it with plugins. I’ve started to consider how create a plugin system. (e.g. like Joomla’s)
I have some doubts about how to do this. I have searched over the net and I found that there are two potential solutions.
using interfaces or abstract classes to implement methods and a plugin-structure, load the assembly, cast the object to the interface and call the methods that the plugins should have when i need to hook the system.
using C# events to load the assembly and raise the events where I need to hook the system. The plugin in the constructor will register the function with the event provided by my application.
What is the best solution? What performance considerations are there? What other approaches could there be?
Rather than writing your own plugin system, you should probably consider the Managed Extensibility Framework (MEF) which is Microsoft's own plug-in framework.
Have a look at the Orchard project on Codeplex. The Microsoft developers have build a plugin mechanism similar to what you are describing. Its pretty complex stuff...
I'm starting a new project which would greatly benefit from program add-ons. The program in its most basic form reads data from a serial port and parses it into database records. Examples of add-ons that could be written would be an auto-archive add-on, an add-on to filter records, etc. I'm writing both the program and the add-ons, but some customers need custom solutions, so instead of branching off and making a completely separate program, add-ons would be great. The simplest add-on would probably be a form who's constructor takes an object reference, manipulates the object in some way, then closes.
Unfortunately, I have absolutely no idea where to start coding, and almost as little idea where to search. Everything I search for turns up browser add-ons. From what I have gathered, I need to look into dynamic loading DLLs. Besides that, I'm clueless. Does anyone have any good resources or examples I that they know of?
I'm happy to provide more details, but this project is in its inception, so I don't have a ton of specific details (specifics kind of defeats the point of add-ons, too.)
You should seriously consider using the Managed Extensibility Framework (MEF) to handle your plugin architecture. It requires thinking about things a little differently, but it is well worth the mind-stretch.
This is a simple example to illustrate the basic technique.
codeproject.com - Plugin Architecture using C#
This article demonstrates to you how
to incorporate ... as a
plugin for another application or use
it as a standalone application.
in .NET 4 you now have the Managed Extensibility Framework (MEF) to do much of the plumbing.
In .NET 3.5 you had the System.AddIn but it was deemed by many to be far too complex.
codeproject.com - AddIn Enabled Applications with System.AddIn
AddIns (sometimes called Plugins) are
seperately compiled components that an
application can locate, load and make
use of at runtime (dynamically). An
application that has been designed to
use AddIns can be enhanced (by
developing more AddIns) without the
need for the orginal application to be
modified or recompiled and tested
You really need to look at Managed Extensibility Framework (MEF). This is specifically designed to help support add-ons and other extensibility.
A very basic description (basically, your plugins must implement a special interface):
http://martinfowler.com/eaaCatalog/plugin.html
Much better article, in C#:
http://www.drdobbs.com/184403942;jsessionid=TVLM2PGYFZZB1QE1GHPCKHWATMY32JVN
I think Reflection will play a major role.
I expirimented with an app that had a plugin folder. A filesystem watcher would watch the folder, and when a new DLL was placed in it, it would use reflection to determine which types of plugins it included, loaded them, and added them to the list of available classes, etc.
Try using the term 'add-in' or 'plug-in' for your research instead of 'add-on'. That should help some.
If you're using .Net 4, there's an add-in namespace in the framework that will get you partway there.
Writing plug-in support for an app is no simple task. You'll have to maintain pretty strict separation-of-concerns across your interfaces, you'll need to provide an interop library that defines ALL of the supported plug-in types, and you'll want to do some research into dependency injection & inversion of control, in addition to the previously-suggested reflection research.
It sounds like you might have a busy weekend doing research.