Scripting Engine for asp.net application - asp.net

I want to allow my users to use a script language to further customize my application.
I´m looking for an embeddable script engine that is thread safe, because it´s a ASP.NET application. I Checked some engines, like Javascript.NET (https://github.com/JavascriptNet/Javascript.Net ) but it is not Thread safe. Other implementations I found do not look stable enough.
Any sugestions ?
Thank you,
Fábio

Perhaps IronPython or IronRuby under the DLR is suitable?
You can mark up your extension points using MEF, and allow scripts to extend your application's functionality.
We've used it successfully in MahTweets (a WPF Application) - but I can't vouch for it's use under an ASP.NET situation.
Of course, thread safety is going to be your least concern if you're allowing random people to run arbitrary code within your application. They'll have full capabilities to completely bypass any security functionality you have, and alter/copy any user data.
Caveat Emptor..

You could also use Lua with something like LuaInterface (http://code.google.com/p/luainterface/). Depending on your level of abstraction and/or freedom for the user writing the script, you may have to refactor a lot of code if you want to introduce a scripting engine.

Related

Make a .Net DLL Thread-safe for Web App Consumption?

I've written a class in VB.Net that is consumed in an ASP.NET Web Application running IIS7. I use .NET Framework 4.0. The class performs a REST request to an online and retrieves an XML response containing strongly typed data.
This class also performs caching using an SQL Server database. The class is compiled to a .DLL and referenced by the Web Application. It works excellent and now I need to know how to make the class thread-safe.
I have no experience with making code 'thread-safe'. I don't know where to begin in determining whether or not it is thread-safe. Am assuming, because I didn't pay attention to this during development, that it is NOT thread-safe and that since it the web application will be used by many users at the same time that it must be payed attention to.
Can anyone point me on how to test for thread-safety? Are there any resources online that that will give me some ideas? Are there any rules of thumb that will tip me off as to where my main concerns are?
The easiest possible thing you can look out for is the use of "static" (C#) or "Shared" (VB.NET) variables. If these variables can be modified throughout the lifetime of the application you will likely run into threading issues which can really often result in "random looking" problems.
I would also be concerned about how you are doing the caching in your database as multiple .NET threads hitting SQL (for the cache) could cause issues as well depending on how its designed.
Bottom line is you are likely going to need to learn more about threading if you want to be sure this is going to not have issues. Probably the best book I have ever read in terms of simple to very complex C# topics is C# 4.0 In a Nutshell I would take a look at that book especially the threading chapters. (Seriously read the whole thing though) If you get that read through and have a good understanding of the concepts mentioned you should be fine.

Implementation of a ASP.NET based portal-like application

There is the requirement, to write a portal like ASP.NET based web application.
There should be a lightweigted central application, which implements the primary navigation and the authentication. The design is achieved by masterpages.
Then there are several more or less independent applications(old and new ones!!), which should easily and independent be integrated into this central application (which should be the entry point of these applications).
Which ways, architectures, patterns, techniques and possibilities can help and support to achieve these aims? For example makes it sense to run the (sub)applications in an iframe?
Are there (lightweighted and easy to learn) portal frameworks, which can be used (not big things like "DOTNETNUKE")?
Many thanks in advance for you hints, tips and help!
DON'T REINVENT THE WHEEL! The thing about DotNetNuke is that it can be as big or as small as you make it. If you use it properly, you will find that you can limit it to what you need. Don't put yourself through the same pain that others have already put themselves through. Unless of course you are only interested in learning from your pain.
I'm not saying that DNN is the right one for you. It may not be, but do spend the time to investigate a number of open source portals before you decide to write your own one. The features that you describe will take 1000s of hours to develop and test if you write them all from scratch.
#Michael Shimmins makes some good suggests about what to use to implement a portal app with some of the newer technology and best practice patterns. I would say, yes these are very good recommendations, but I would encourage you to either find someone who has already done it this way or start a new open source project on codeplex and get other to help you.
Daniel Dyson makes a fine point, but if you really want to implement it your self (there may be a reason), I would consider the following components:
MVC 2.0
Inversion of Control/Dependency Injection (StructureMap for instance)
Managed Extensibility Framework
NHibernate (either directly or through a library such as Sh#rp or Spring.NET
A service bus (NServiceBus for instance).
This combination gives you flexible user interface through MVC, which can be easily be added to via plugins (exposed and consumed via MEF), a standard data access library (NHibernate) which can be easily configured by the individual plugins to connect to specific databases, an ability to publish events and 'pick them up' by components composed at runtime (NServiceBus).
Using IoC and DI you can pass around interfaces which are resolved at runtime based on your required configuration. MEF gives you the flexibility of defining 'what' each plugin can do, and then leave it up to the plugins to do so, whilst your central application controls cross cutting concerns such as authentication, logging etc.

How to make two web sites appear as one - What features are important?

I am about to write a tender. The solution might be a PHP based CMS. Later I might want to integrate an ASP.NET framework and make it look like one site.
What features would make this relatively easy.
Would OpenId and similar make a difference?
In the PHP world Joomla is supposed to be more integrative than Druapal. What are the important differences here?
Are there spesific frameworks in ASP.NET, Python or Ruby that are more open to integration than others?
The most important thing is going to be putting as much of the look-and-feel in a format that can be shared by any platforms. That means you should develop a standard set of CSS files and (X)HTML files which can be imported (or directly presented) in any of those platform options. Think about it as writing a dynamic library that can be loaded by different programs.
Using OpenID for authentication, if all of your platform options support it, would be nice, but remember that each platform is going to require additional user metadata be stored for each user (preferences, last login, permissions/roles, etc) which you'll still have to wrangle between them. OpenID only solves the authentication problem, not the authorization or preferences problems.
Lastly, since there are so many options, I would stick to cross-platform solutions. That will leave you the most options going forward. There's no compelling advantage IMHO to using ASP.NET if there's a chance you may one day integrate with other systems or move to another system.
I think that most important thing is to choose the right server. The server needs to have adequate modules. Apache would be good choice as it supports all that you want, including mod_aspnet (which I didn't test, but many people say it works).
If you think asp.net integration is certanly going to come, I would choose Windows as OS as it will certanly be easier.
You could also install reverse proxy that would decide which server to render content based on request - if user request aspx page, proxy will connect to the IIS and windoze page, if it asks for php it can connect to other server. The problem with this approach is shared memory & state, which could be solved with carefull design to support this - like shared database holding all state information and model data....
OpenID doesn't make a difference - there are libs for any framework you choose.

What should I be aware of when moving from asp.net to python for web development?

I'm thinking about converting an app from Asp.net to python. I would like to know: what are the key comparisons to be aware of when moving a asp.net app to python(insert framework)?
Does python have user controls? Master pages?
First, Python is a language, while ASP.NET is a web framework. In fact, you can code ASP.NET applications using IronPython.
If you want to leave ASP.NET behind and go with the Python "stack," then you can choose from several different web application frameworks, including Django and Zope.
Zope, for example, offers a pluggable architecture where you can "add on" things like wikis, blogs, and so on. It also has page templates, which are somewhat similar to the ASP.NET master page.
I second the note by Out Into Space on how python is a language versus a web framework; it's an important observation that underlies pretty much everything you will experience in moving from ASP.NET to Python.
On a similar note, you will also find that the differences in language style and developer community between C#/VB.NET and Python influence the basic approach to developing web frameworks. This would be the same whether you were moving from web frameworks written in java, php, ruby, perl or any other language for that matter.
The old "when you have a hammer, everything looks like a nail" adage really shows in the basic design of the frameworks :-) Because of this, though, you will find yourself with a few paradigm shifts to make when you substitute that hammer for a screwdriver.
For example, Python web frameworks rely much less on declarative configuration than ASP.NET. Django, for example, has only a single config file that really has only a couple dozen lines (once you strip out the comments :-) ). Similarly, URL configuration and the page lifecycle are quite compact compared to ASP.NET, while being just as powerful. There's more "convention" over configuration (though much less so that Rails), and heavy use of the fact that modules in Python are top-level objects in the language... not everything has to be a class. This cuts down on the amount of code involved, and makes the application flow highly readable.
As Out Into Space mentioned, zope's page templates are "somewhat" similar to ASP.NET master page, but not exactly. Django also offers page templates that inherit from each other, and they work very well, but not if you're trying to use them like an ASP.NET template.
There also isn't a tradition of user controls in Python web frameworks a la .NET. The configuration machinery, request/response process indirection, handler complexity, and code-library size is just not part of the feel that python developers have for their toolset.
We all argue that you can build the same web application, with probably less code, and more easily debuggable/maintainable using pythonic-tools :-) The main benefit here being that you also get to take advantage of the python language, and a pythonic framework, which is what makes python developers happy to go to work in the morning. YMMV, of course.
All of which to say, you'll find you can do everything you've always done, just differently. Whether or not the differences please or frustrate you will determine if a python web framework is the right tool for you in the long run.
Most frameworks for python has a 'templating' engine which provide similar functionality of ASP.NET's Master pages and User Controls. :)
Thanks for the replies Out Of Space and Jarret Hardie

Add ons in a compiled language

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.

Resources