We are developing a CMS in ASP.NET. We love the idea of add-ons (like in Wordpress, where any developer can add a menu button or a widget) and would like to enable developers to do the same with our system.
However I think that the fact that C# is a compiled language is an obstacle in the way of add-ons.
Am I right? Or is there a way to create add-ons for a ASP.NET application?
The fact that C# is a compiled language isn't a problem at all. In fact the .NET framework should make it relatively easy to load other code (just as Java does, for the same reason). Look into the Managed Extensibility Framework, which is all about loading Add-Ons in managed code.
It's not an obstacle at all. MEF has already been mentioned, you could also use:
System.Addin
Mono.Addins
I'm not sure for ASP.NET specifically, but in the only compiled programming language I know (Objective-C/Cocoa), there's the concept of Bundles that can be loaded dynamically. I'm not sure how that works on the backend, but I'd guess that there is some similar system for C#/ASP.NET.
I don't know how it's done in Wordpress, but there should be many ways. You can allow developers to upload their assemblies with compiled code or you can allow them to upload code in C# or IronPython or anything that supported and compile it dynamically. Maybe you can use WebParts for your task.
Microsoft has created the Managed Extensibility Framework (MEF), specifically for this problem: providing .NET plugins for .NET applications. It is the framework that (future versions of) Visual Studio use for writing managed plugins.
However, please consider using a dynamic scripting language for this! Problems like this are exactly what they are specifically designed for. If you host the Dynamic Language Runtime in your application, it not only means that your users can extend the application in a scripting language, but even in any dynamic language (scripting or otherwise) for which a DLR implementation exists: Ruby, Python, Smalltalk, Scheme, JavaScript, PHP, you name it. Biggest disadvantage: the DLR hasn't been released yet.
In C#, you can create any assemblies, link them as DLL files and then do whatever you want.
The usual case would be to define some kind of Plugin Interface which must be implemented by all the plugins.
Then you can load all plugins from the filesystem (by iterating over the plugin DLLs), find the class inside which implements the interface, instantiate it and work with it.
If you want to provide plugins with unloadability and security, you could create an application domain and load the plugins to that, increasing complexity, but also increasing stability (a bad plugin won't crash your app).
Please ask more specifically if you want a specific answer :-)
It's not too difficult to put hooks in place. You have to define in advance where the add-on features will appear. For example: when drawing a menu you can use reflection to search other dlls (with specific names and locations) for a "BuildMenu" function. You'll be defining the API for this function signature. It may have to return a list of items to be added to the base menu items collection.
Related
I plan to build a database management system using Grails as the main framework. On the client side, I'm thinking whether to use dojo or flex to make a nice front end.
Could some experts here enlighten me on the pros and cons of choosing either, or both?
or any other options?
thanks!
I tried using Dojo in a project and even brought a few books. And while Dojo Looks good I found that JQuery and JQuery-UI was a lot lighter and worked faster.
This is just my opinion and it may help you.
From the description of the flex plugin at http://www.grails.org/Flex+Plugin
"This plugin was created as an experiment to prove that it's possible to communicate from Flex to Grails services without any configuration in Flex. There
is no plan to add functionality or whatsoever. It's not sure if the plugin works in production mode as it is only tested in development mode. This plugin
can be seen as an example on how to integrate Flex and Grails with Convention over Configuration in mind."
There is no scaffolding generation for flex, see this bug
Another disadvantage of Flex is its lack of accessibility for screen reader users with the default configuration. There is some work being done to address this but it isn't publically available yet.
I don't have experience with DOJO but according to this link if you use the standard Grails Ajax tags you should be able to switch libraries with out to much trouble and won't be tied to Dojo. For fancy UI stuff such as tabbed interfaces and data tables I've found GrailsUI works well for me. A demo project showing its features can be found at http://code.google.com/p/guidemo/ although you'll have to check the code out to run it.
I am developing an information-management application with Dojo 1.9.2 and Grails 2.3.9 (lots of simle/complex forms, listing screens...etc). The application has a single-page interface as well (a workspace) which was the primary reason for a heavy JavaScript library.
Overall, Dojo is fairly suitable for this kind of workload and I haven't bumped into any show-stoppers yet.
I needed to do a lot of work on integrating the Dojox DataGrid into the application (extending QueryReadStore to fit with Grails better...etc) and a set of custom widget extensions (e.g. a real, working AutoComplete).
After this larger, initial integration work is done, you can expect a fairly smooth ride.
We have a series of ASP.Net applications that have been written over the course of 8 years. Mostly in the first 3-4 years. They have been running quite well with little maintenance, but new functionality is being requested and we are running into IDE and platform issues. The apps were written in .Net 1.x and 2.x and run in separate spaces but are presented as a single suite of applications which use a common navigation toolbar (implemented as a user control). Every time we want to add something to a menu in the nav we have to modify it in all the apps which is a pain. Also, the various versions of Crystal reports and that we used tables to organize the visual elements and we end up with a mess, especially with all the multi-platform .Net versions running. We need to streamline the suite of apps and make it easier to add on new apps without a hassle. We also need to bring all these apps under one .Net platform and IDE.
In addition, there is a WordPress blog styled to match the style of the application suite "integrated" into the UI and a link to a MediaWiki Wiki application as well.
My current thinking is to use an open source content management system (CMS) like Joomla (PHP based unfortunately, but it works well) as the user interface framework for style templating and menu management. Joomla's article management would allow us to migrate the Wiki content into articles which could be published without interfering with the .Net apps. Then essentially use an IFrame within an "article" to "host" the .Net application, then...
Upgrade the .Net apps to VS2010, strip out all the common header/footer controls and migrate the styles to use the style sheets used in the CMS.
As I write this, I certainly realize this is a lot of work and there are optimization issues which this may cause as well as using IFrames seems a bit like cheating and I've read about issues with IFrames.
I know that we could use .Net application styling, but it seems like a lot more work (not sure really). Also, the use of a CMS to handle the blog and wiki also seems appealing, unless there is a .Net CMS out there that can handle all of these requirements.
Given this information, I am looking to know if I am totally going in the wrong direction? We tried to use open source and integrate it over time, but not this has become hard to maintain. Am I not aware of some technology out there that will meet our requirements? Did we do this right and should we just focus on getting the .Net streamlined? I understand that no matter what we do, it's going to be a lot of work. The communities considerable experience would be helpful. Thanks!!
PS - A complete rewrite is not an option.
Hmm, we're in the midst of a project to do something that sounds familiar. We're using www.sitecore.net CMS but you could use the Open Source alternative Umbraco again both of these will have a learning curve, but they're .Net apps and aren't targetted specifically at blogs. SiteCore ultimately can use normal .Net user controls if you want, though it's slightly against their model, but it works.
One thing I'll warn you of is SiteCore Must be the root of your website, it has to control the root of the domain (it has a urlrewriting module that needs to be at the root) and you can tell it to exclude certain folders where your applications might live. You can obviously put your navigation in a folder under the root of the site. Also note SiteCore's a .Net 3.5 application running under the 2.0 runtime.
Are your sub-applications.. Actual seperate applications in virtual dirs or something I'm guessing?
Depending on the nature of the .Net apps, you may find DotNetNuke to be a useful choice.
It's a CMS where you write widgets ('modules') in .Net, then add them to the pages of the CMS. In your case, you'd wrap your existing functionality in such widgets. I've done exactly this several times, and now that I'm used to it it's no big deal.
The downside is you have to learn to swim in the DNN environment, which (like any CMS) has a bit of a learning curve.
I'd have to know a lot more about your existing apps to be sure this is a plausible option. If it looks appealing, you should probably contact someone who's dealt with a situation like yours (such as myself) and go into detail. It's very easy to find yourself in a dead end with these CMS frameworks.
Edit: Like a product mentioned in a different answer, DNN has to control the top level of its subdomain -- all requests begin by going through Default.aspx and are then dispatched in various ways.
I had an application built on top of DNN. We created a few custom DNN modules for it. Now the functionality is required in another application that is not going to be built on DNN but on plain old ASP.NET. The question is that can the existing modules somehow be reused as is in other applications as plain UserControls somehow??
Well yes a no
If the logic and security of the module are not depedent on any of the dnn namespaces then its easy but if they are then you may have to rewrite and rethink - really though in my opnion once you have built a module its easy to rebuild it without dnn after all the real challenge is getting the logic to work that first time.
It depends.
If you have a deep level of integration with DNN (eg exceptions, user accounts ect) you will have to swap those pieces out for whatever you will be using on the vanilla ASP.NET WebForms site.
Basically, it "can" be done but with a bit of work.
Now before I dive too far into this this question, I am aware of nDjango and MonoRail; however, those project seem to be lacking.
What I'm wondering is if there is a solution out in the .Net world that has the following features out of a single box like Rails has in Ruby or Django has for Python. I know tools that do pieces but am curious if there's 1 unified solution out there.
Database Versioning/Migrations
ORM or similar code gen
MVC-based
Pre-generated administrative screens
View generation
Theming / styling
(I'm sure I'm forgetting another cornerstone feature)
There's lots of options that cover one or more of these aspects but is there something in .Net that covers all of them?
Thanks
I have not yet found a solution as you have described, but as you know there are bits and pieces that could be used together to provide a stack that is close:
Database Versioning/Migrations - DotNetMigrations
ORM or similar code gen - Nhibernate, Entity Framework
MVC-based - native to ASP.NET MVC
Pre-generated administrative screens - PLINQO
view generation - available in Entity Framework or CodeSmith templates, PLINQO
Theming / styling - native to ASP.NET
This would provide a stack that is .NET and not another ecosystem sitting on top of a .NET substrate.
You can actually run Rails under the .NET DLR. This allows you to not only access the feature set Rails provides, but also everything else which is available in the .NET ecosystem.
I haven't found a one click installer which gives me everything on your list, but, as you say, I have found excellent solutions for each point on your list which integrate well.
I'm honestly not sure how close this gets you, but S#arp Architecture seems to be trying to cover a lot of this ground in a single package.
There is a django for .net, the name is django!
In the web there is a lot of post about django running with ironpython (a implementation of python for the "virtual machine" of C#, CLR, i think)
there is also ndjango - the django templating language written in f# for .net. you can use it with bistro or asp.net mvc (or whatever else that you plug it into)
If you distribute a .net web application, and you want a certain module of the application to be disabled, AND you don't want to ship the source with it, is it a reasonable solution to just not include the necessary .dll for that module?
I know you can do things programatically, but as long as you don't ship the .dll things should be ok right?
Reason being some .dll's require you to sell the product commercially, and if I want to give it away for free or as a demo I am stuck.
You have to go for plugin architecture. There's plenty of questions here on SO, as well as MEF which will be used in Visual Studio 2010, plus loads of DI/IoC containters which can aid in creating plugin-based apps.
You should be okay as long as the binary image you do ship doesn't actually need anything in the dll you're not shipping. That includes "does not expose functionality provided by the missing dll's".
For example; don't expose the "download as pdf" button if your pdf tools aren't "installed".
I've done this before by having a sort of plugin system that scans a predefined directory for .dlls and building a list of all exposed classes implementing a certain interface. Might be overkill for what you want though, and it's kindof the other way around than you suggest.
One possible approach (assuming you don't want to or can't go the plugin route) would be to create a dummy DLL with all the same classes and methods in there but that actually doesn't do anything.
Depending on the size and complexity of your DLL this may or may not be a viable action.
The plugin route would be the way I'd approach it though, as whenever the "real" DLL changes you will need to update your dummy one.
You definitely need some kind of 'in code' element, because a lack of DLL will break things in a worse way than simply disabling the modules you had intended.
This will definitely break if you are using Web Site instead of Web Application Project, because the DLL reference must be in your web.config... which will throw an error when it's missing.
You could get away with it in a Web Application Project, but that's a pretty ugly method. Much better to use some sort of plugin architecture, as others suggest.