The majority of material I have found regarding DLR is related to IronPython. Can you parse and execute C# using DLR? If so is there over head that would prevent you from attempting this on a web server with about 30 users?
More specifically I would like to script the configuration of my workflow objects when a user first initiates a workflow. Depending on conditions that change through out the year workflows may start at different steps, hence running configuration scripts seems like a good way to handle the variation.
It sounds like you're really talking about the C# "compiler as a service" (at the end of this video), which will hopefully be in the 5.0 timescale for .NET (although Mono has it now). For now, CSharpCodeProvider is the best we have (which works largely like "csc").
Although Marc offered an alternative for me, I read this related SO question and C# and VB are not supported as of yet.
You may find this relevant...though it doesn't run on the DLR itself.
Mono Compiler as a Service (MCS)
It has the advantage of running snippets and not loading a new assembly on every compile like CodeDom does.
Related
I'd like to give user the opportunity to do its own report based on my class hierarchy (object in memory). A scripting language like VBA: Visual Basic for Application. Something that would be evaluated at runtime.
I'd like the user to be able to dynamically create its own report based on some available restricted objects marked with specific attributes only. Give user possibility to create macro where he have similar model as in VBA-Excel : Application/Workbook/WorkSheet/Range/... but with my specific selected objects instead.
Then, he would have been able to use intellisense and add its own functionality to its application.
Update: There is something very important that appears to me. The editor should be preferably part of the application itself in order for the script to know all the environment (namespace, objects, ...) it should interact with. Otherwise, having a scripting engine/editor in a separate process would force the application to be either a "single-instance" app or to create a tricky way to hook the script to a specific running application process.
Does it exists and how to plug it to a .net app?
4 solutions have been proposed:
IronRuby
CsScript
WinWrap
Windows Scripting Host (WSH)
I also found:
ScriptCs
RoslynPad
Code Project - Anoop Madhusudanan article: C# as a Scripting Language in Your .NET Applications Using Roslyn
But I wonder which one could fits every needs (or most of them):
Editor with Intellisense
User have access the currently running process object model (Application as global and all its related objects accessed through application properties). Optional but very nice to have: not necessarily every public properties, only marked ones with specific attributes.
Interactive environment enabling step by step, debugging, breakpoints, ...
Editor/debugger Licensed for free redistribution
Not required, but preferably use C# language
Actual testing:
I tried to evaluate #2 but there is no VS project sample with all modules working together (which seems a little bit complex to assemble).
I currently evaluate #6 which seems to work fine (I corrected a minor bug). It seems to fits most points but #3. But it seems to be the closest to my needs yet. It also uses Roslyn which appears to me a positive aspect because it is the Microsoft compiler which should always be up to date.
I'm still waiting to see any feedback from anybody with either other better solutions or any advise to help me take a better decision.
After some thought, trials and errors. My needs become clearer and my understanding of to current state about Roslyn development was also better.
I realized that Oleg Shilo (Author of CS-Script) was right about the fact that Roslyn is not ready (2014-10-21) to help me for intellisense. But I think it should happen relatively soon. I think it should worth the wait. But it can compile and run code into the same running app I would like to run tested in.
Although any other approach could have probably work better right now. I think that a solution like RoslynPad would be closer to the ideal solution for my needs. Most other proposed solution where nice for general scripting but not as good as RoslynPad for inside app own scripting... at least according to my opinion.
I then fixed some little issues in RoslynPad and hook it to the newest AvalonEdit which also fixes some other issues with auto-completion (but still with few bugs).
I now get needs filled up as this:
#1 Partial (ready for full when Roslyn will supported and documented it)
#2 Full
#3 No (ready for full when Roslyn will supported and documented it)
#4 Full
#5 Full
Thanks a lots to all people giving me ideas, links and very nice advise.
We currently use IronPython as a scripting language to allow our business users to configure large portions of our application and we are evaluating the possibility of adding in C# as a scripting language once Roslyn is released. For IronPython, we use Microsoft.Scripting.Hosting.CompiledCode to cache the compiled code and execute it against different ScriptScope object.
Looking around the latest Rosyln CTP I don't see an obvious way to compile code and then execute it against different Sessions or hostObjects. Is this functionality available at this time, and if not, is it going to be available at release?
We currently are looking at supporting the same scenario with the Roslyn Scripting APIs, that is, to compile the code so that you can execute it independently against different scopes. It will likely be a bit different than the DLR Hosting APIs, and by the time we ship, plans could completely change. I should post my updated scripting spec. I haven't done so already since we did not do much work on the Interactive/scripting area for CTP2, focusing ore on the compiler APIs. We have sketched out the direction we're thinking in regards to your question. I'll try to do that today, so on the Roslyn forum, see the pinned post at the top of the forum, which I'll update with a link to the updated spec.
Thanks,
Bill
I don't know a whole lot about Roslyn but it looks like this would accomplish what you're after. Loading an assembly generated by the Roslyn compiler
I'm diving into web development after ten years of desktop development and I'm experimenting with some testing concepts. I was wondering if it's possible to sandbox and run C++ code that's entered in a textfield in a browser? By that, I mean run the C++ or C# code on the backend webserver and return an analysis of the code. Just to be clear, I don't mean run C++ or C# code that's intended to generate any kind of markup, but simply to blackbox test the C++ or C# block of code that's entered.
How would you invoke the compiler, depending on the web server you're using?
How could you sandbox the code to prevent malicious behavior? If we're considering only one of the C variants, what about blacklisting/whitelisting specific functions and libraries to prevent malicious behavior? Or would that blacklist be too long and too limiting to allow any fair amount of code to run?
These are some fairly high-level questions that I'm asking just because I'm having a hard time finding some direction, but I'm going to continue researching them right now. Thanks so much in advance for your help!
You might find the codepad about page interesting.
# 1 is easy with C#. The Reflection capabilities of .NET allow you to compile and run code "on the fly." And here's a link to another good looking tutorial.
# 2 is a little more difficult but I suppose a basic sand boxing technique might involve executing a dynamic process under a limited, and therefore sand boxed account. Programmatically you could analyze the dynamicly built assembly's dependencies and not allow it to run if it used APIs in certain namespaces such as System.IO. This is non-trivial to say the least though.
C++ doesn't have reflection capabilities and so 3rd party libraries would be your best bet.
The Dinkumware site has something like this.
A simple Perl (or Python, ...) cgi could be used to invoke the compiler, parse it results, run the resulting executable if any and display it's results.
I would take a look at SELinux (maybe AppArmor?) for access controls. Maybe not allowing it write and read to/from the disk and limit it's running time. I don't know if the later can be done with SELinux, too.
If the server runs Linux, you may consider using chroot
We actually did just that with our product called iKnode. We are using this idea to create a Backend in the cloud.
We did this by creating a SandBox that takes an specific piece of code and executes it, captures the result and returns it to the user. This is all done in the cloud.
How would you invoke the compiler, depending on the web server you're
using?
We did this by using the CodeDom utilities from the .Net framework. And we are exploring the coming 'compiler as a service' project coming from Microsoft code-named Roslyn.
This is a good starting point on using CodeDom to programatically compile.
How could you sandbox the code to prevent malicious behavior? If we're
considering only one of the C variants, what about
blacklisting/whitelisting specific functions and libraries to prevent
malicious behavior? Or would that blacklist be too long and too
limiting to allow any fair amount of code to run?
We did this by wrapping the code execution in a separate and limited AppDomain. You can see some examples here.
Additionally, you might want to look into the MonoSandBox, which was created for Moonlight, but it is a more robust SandBox. We are experimenting with it right now, to move away from AppDomains. We believe the MonoSandBox is way better than simple AppDomains.
I wrote a CSharpScriptBinding roughly equivalent to the PyBinding on CodePlex. It uses the C# script engine from http://www.csscript.net.
After I wrote it, I kind of decided it might not really be something good to use. Although it caches the compiled script code as an already compiled Assembly, my concern is that I will have one temporary Assembly created each time I use the binding. Will this add up to a problem in the future? If so, maybe there is a way in the C# script engine that I don't know about to optimize this further...? Any thoughts to confirm my suspicion that this was just a bad idea (but useful excersise in learning more about bindings and converters)?
Ask them if they use the DLR? Without it, I wouldn't trust it.
Problem
Language: C# 2.0 or later
I would like to register context handlers to create menues when the user right clicks certain files (in my case *.eic). What is the procedure to register, unregister (clean up) and handle events (clicks) from these menues?
I have a clue it's something to do with the windows registry, but considering how much stuff there is in .net, I wouldn't be surprised if there are handy methods to do this clean and easy.
Code snippets, website references, comments are all good. Please toss them at me.
Update
Obviously there is a slight problem creating context menues in managed languages, as several users have commented. Is there any other preferred way of achieving the same behaviour, or should I spend time looking into these workarounds? I don't mind doing that at all, I'm glad people have put effort into making this possible - but I still want to know if there is a "proper/clean" way of achieving this.
Resist writing Shell Extensions in managed languages - there are a multitude of things that could go bang if you pursue this route.
Have a browse through this thread for more details. It contains links to do it if really want, and sagely advice of why it can be done, but shouldn't.
http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/1428326d-7950-42b4-ad94-8e962124043e/
You're back to unmanaged C/C++ as your only real tools here.
This is not a good idea because of potential dependency issues between different versions of the .NET Framework. Your shell extension could be expecting one version, while a different version may have already been loaded by the application that's currently running.
This thread contains a good summary of the situation.
While others already mentioned that writing shell extensions in pure .NET is a bad idea due to framework conflicts, you should still note that:
There are 3rd party drivers out there (see Eldos or LogicNP) that do the unmanaged side for you, allowing you to write managed code that talks to the native driver, thus preventing shell-related CLR version conflicts.
A recent MSDN article mentioned that Microsoft has solved this problem for the CoreCLR, as used by Silverlight. They've accomplished this by allowing multiple versions of the CLR to run in the same process, thus fixing the problem. The author further stated that this fix in Silverlight will be rolled into future versions of the full CLR. (Meaning, in the future, it will be quite feasible to write shell extensions in managed code.)
I've done them before in C#. It ends up being a hell of a lot harder than it should be. Once you get the boilerplate code down, though, it is easy to roll out new items. I followed this link:
Link To Info
As the prior comments mention, it isn't the best idea to write shell extensions in managed languages, but I thought I'd share an Open Source project that is doing just that :)
ShellGlue is a managed shell extension that is actually quite helpful. The source also might be helpful to you if you're interested in pursuing writing a shell extension in C/C++.
Aside from the caveats that have been mentioned concerning the implementation of shell extensions in managed code, what you'd basically need to do is the following:
First, create a COM component in C# that implements the IShellExtInit IContextMenu interfaces. How to create COM components in C# is described here. How to implement the necessary interfaces is described in this article. While the description is for a C++ implementation, you can apply that knowledge to you C# version.
Your COM component will have GUID called the Class-ID or CLSID. You need to register that ID with your file type as a context-menu shell extension:
HKEY_CLASSES_ROOT\.eic\ShellEx\ContextMenuHandlers\MyShellExt
(Default) -> {YOUR-COMPONENTS-CLSID}
Also make sure that you registered your component correctly as described in the C# COM tutorial. You should find it in the registry under
HKEY_CLASSES_ROOT\CLSID\{YOUR-COMPONENTS-CLSID}
InprocServer32
(Default) -> C:\WINDOWS\system32\mscoree.dll
Class -> YourImplClass
assembly -> YourAssembly, version=..., Culture=neutral, PublicKey=...
...
Good luck...
As others have pointed out, shell extensions are not practical in windows development currently.
I asked a similar question recently which was answered with a link to a guide to do exactly what I wanted to do