|
|
Comments and Discussions
|
|
 |

|
Really good so thank you Petro.
|
|
|
|

|
great idea; would love to have native support in C# for scripting...
|
|
|
|

|
How can I include an embedded single quote in a string literal?
using ScriptDotNet;
Script s = Script.Compile("MessageBox.Show('This doesn't work.');");
s.AddType("MessageBox", typeof(MessageBox));
s.Execute();
How can I escape the single quote? I tried the following...
Script s = Script.Compile("MessageBox.Show('This doesn''t work.');");
Script s = Script.Compile("MessageBox.Show('This doesn\'t work.');");
Thanks!
Kevin
|
|
|
|

|
Did you find a solution to that?
|
|
|
|

|
Please post your questions at SSharp to get faster reply.
Escaping is indeed supported in S# strings. You should rewrite your example like this:
Script.RunCode("MessageBox.Show('This doesn\\'t work.');");
|
|
|
|

|
Great code. Great article. why don't you update it to match IronyScriptDotNet
|
|
|
|

|
Thanks and I am continuosly working to improve it. That is why I don't have time to update the article. But you are right I should update it and I'll definitely do that.
|
|
|
|

|
i was looking for some thing like ms script control for .net that would be easy to use and would allow extension using .net objects. Script# saves the day.Got my 5.
|
|
|
|

|
Piter,
I have just tried using a simple script that works on one PC on another PC, with different results.
This is the script:
for (i = 0.0; i < 5; i += 0.5)
{
WriteText("Abs(" + i + ") = " + Abs(i) + "CRLF");
}
It is meant to calculate the absolute of i. WriteText() outputs the text on screen and the "CRLF" adds "\r\n".
This is the correct output on the first PC (It doesn't do anything to the values, as all i's are positive):
Abs(0) = 0
Abs(0.5) = 0.5
Abs(1) = 1
Abs(1.5) = 1.5
Abs(2) = 2
Abs(2.5) = 2.5
Abs(3) = 3
Abs(3.5) = 3.5
Abs(4) = 4
Abs(4.5) = 4.5
Here's the output of the second PC, using the same three lines of code:
Abs(0.5) = 0
Abs(1) = 1
Abs(1.5) = 2
Abs(2) = 2
Abs(2.5) = 2
Abs(3) = 3
Abs(3.5) = 4
Abs(4) = 4
Abs(4.5) = 4
This is obviously wrong.
The only thing I can think of is a difference in the .NET versions on the two computers. The PC where it works has .NET 1.1 and .NET 2.0. The PC where it doesn't work has .NET 1.1, .NET 2.0, .NET 3.0 and .NET 3.5 installed.
Any idea what could cause this?
Thanks in advance.
Christian
|
|
|
|

|
Please don't be confused by the "'s in the code. They are replaced by ' in a preprocessor.
Christian
|
|
|
|

|
I have now removed .NET 3.0 and .NET 3.5 from the second PC. Still no improvement.
|
|
|
|

|
I will investigate your problem and will come back as soon as possible
|
|
|
|

|
Piter,
thanks. I have tried a few others, like Math.Ceiling() and Math.Cos() and they work as expected.
Christian
|
|
|
|

|
Hello,
Please check the issue on the up-coming release. If it will be still reproducible give me a note on piter.protsyk@gmail.com
http://www.protsyk.com/scriptdotnet/versions/130208/
Regards,
Petro
|
|
|
|

|
Petro,
thanks for your answer. I will try it over the next few days.
Christian
|
|
|
|

|
Petro,
With the new version I am getting a few errors:
using ScriptNET;
using ScriptNET.Runtime;
.
.
.
Script s = null;
s = Script.Compile(script);
s.AddBuildInObject(typeof(Math));
s.AddObject("report", report);
s.AddType("DateTimePicker", typeof(DateTimePickerUI));
Note: I have added 'IronyScriptDotNet.dll' as a reference.
All three cause a 'ScriptNET.Script' does not contain a definition for ... error.
Any idea why this could be?
Thanks
Christian
|
|
|
|

|
Hello Christian
It seems that you might use an older version of Script.NET.
Please download the latest by the following link:
http://www.protsyk.com/scriptdotnet/versions/latest/IronyScriptDotNet.zip
Then change a definition:
using ScriptNET;
using ScriptNET.Runtime;
.
.
.
//This should be executed once per application, before executing any script
RuntimeHost.Initialize();
RuntimeHost.AddType("DateTimePicker", typeof(DateTimePickerUI));
Script s = null;
s = Script.Compile(script);
//s.AddBuildInObject(typeof(Math));
// please see using statement
s.Context.SetItem("report", report); // for report generation
Regards,
Petro
|
|
|
|

|
Hi Petro,
unfortunately, this still doesn't work.
The version at this address doesn't contain a definition for 'SetItem' (see s.Context.SetItem("report", report); // for report generation).
The help file doesn't mention using ScriptNET.Runtime;.
Is it possible that this version is not the latest version?
Thanks for your help.
Christian
|
|
|
|

|
Hello Christian,
The help file is not synchronized with the latest code. Sorry for that, the code evolving much more faster than documentation.
Please consider examples that comes together with a script.net solution and take a look at unittests. Unittest should show expected behavior of scripting engine.
Regards,
Petro
|
|
|
|

|
Hi Extrim,
just started playing with this and it looks great, because of its simplicity.
Here's my question: In your example
Script s = Script.Compile(@"form.Text = 'Hello World';
MessageBox.Show('Hi');
b = new Button() ");
s.AddObject("form", this);
s.AddType("Button", typeof(Button));
s.AddType("MessageBox", typeof(MessageBox));
s.AddBuildInObject(typeof(Math));
s.Execute();
the person writing the script will have to type in "form.Text = ..." to change the content of "Text". Is it possible to have them just type "Text = ..." to access form.Text? Hope this makes sense.
There is another aspect: The way the example is written, the person writing the script can access all public variables in "form". This might not be desired and could cause serious problems. Is there a way to limit what the user can access?
Thanks for your answer.
|
|
|
|

|
Hello!
Thank you for your questions. You have rised good points.
Unfortunatelly, now it is not possible to use just object's properties, like "Text = ...".
The only thing you could do is AddBuildInObject which will be acessible for reading.
In this example you could write:
"Pow(2,3)" which will be refered to "Math.Pow(2,3)".
There are also no possibility to limit the users accessability.
However, I will keep your requests in mind. I am planning to release new version of Script.NET engine soon. Hopefully, I will try to implement most of the requests.
Best wishes,
Piter (Extrim)
|
|
|
|

|
Piter,
I would still recommend using it, simply because it is so easy to use.
One question: Is it possible to interrupt a running script from within the C# program?
Thanks
Christian
|
|
|
|

|
...and it's simply brilliant! Easy to use, easy to deploy and it has opened my eyes to the possibility of delivering scriptable applications to my clients.
Well done, and keep up the good work!
|
|
|
|

|
Thank you for sharing this. Regardless of whether this can be done with other tools, the point is that this shows how we can make our own script manager. 5 from me
|
|
|
|

|
but got my five
|
|
|
|

|
The "online test" site attempts to run scripts from a site ominously named "spylog.ru".
May be innocuous, but who knows?
|
|
|
|

|
"spylog.ru" script is simply a counter at the bottom of the page.
|
|
|
|

|
I have been waiting for something like this for 3 years already.
For my desktop application i used to have vbscript files that generate HTML as reports and then they i would open up an IE to show report to user.
And usually there might be tight integration with passing objects and such between application and report. So this solution is perfect for .NET applications.
It allows me to distribute/modify reports on a fly.
|
|
|
|
|

|
strong agree with this. if you truly want to find something to use in your application, you will find it's difficult to get a proper one. some years before I was in a reporting system, I have the same feeling with Jewelry. thanks Extrim for your great job, I will use this next time.
Zhijun Liu
|
|
|
|
|

|
Thank you, for your comment. I'm familiar with F#. But Script.NET is something very different, simply because F# is functional language and Script.NET - imperative.
|
|
|
|

|
Extrim wrote: F# is functional language
You are wrong. F# is mixed paradigm language,- functional and imperative.
|
|
|
|

|
From what I understand, F# was designed for low-level operations. I believe some guys at MS even built a rudimentary OS written in F#. I could be confusing it with another language, tho.
Beside F#, you may also want to take a look at JScript.NET, which is basically MS's incarnation of javascript syntax that more or less complies with the CLS. Plus, the framework comes with a compiler for it, rather than an interpreter.
However, this Script.NET seems promising in its own way. As far as I understand, Script.NET seems to be weak-typed, dynamically typed, or at least duck typed. I don't see a whole lot of strong typing, which may be good for people that are familiar with writing scripts that way.
In any case, keep up the good work
--
Thany
|
|
|
|

|
There is also DLR, Dynamic Language Runtime, so there should soon be more scripting languages available for .NET (like IronRuby).
Michal Blazejczyk
|
|
|
|

|
Actually it'd be good to have this working with the DLR.
|
|
|
|

|
Yes,
I have started thinking about it. And created some initial project.
Who is interested in DLR could find it here: Simple DLR Language
|
|
|
|

|
Very nice article. But you can achieve the same or far more complex funcionality using Windows Powershell.
Anyway, good work, got my 5.
|
|
|
|

|
Can you show me an example then where you can use Powershell to get the same functionality?
|
|
|
|

|
If i want to embed scripting funcionality in my application. I can implement PowerShell PSHost to get basic user interface for scripting. When starting this interface i can load my own assemblies and custom cmdlets. Then I can exploit whole .NET framework and of course my custom object model. I can use third party scripts, cmdlets, or hosts.
We embedded similar thing in our last project and it works really fine.
Peter
|
|
|
|

|
I do agree that the presented solution in its current form is quite limited.
However PowerShell is not the only available alternative. CS-Script is a strongly C# oriented scripting engine (though it supports some other CLR languages too). It offers all advantages you have mentioned for PS. And arguably it has a better integration with OS and common IDEs and also simpler hosting implementation.
http://www.csscript.net/[^]
or
http://www.codeproject.com/csharp/cs-script_for_CP.asp[^]
|
|
|
|

|
Yes, what you said is true, but CS-Script has a significant disadvantage (for my opinion), because it uses run-time compilation and generates new assembly in the memory. In the case where one need to compute a lot of scripting expressions (as for examples formulas in Excel cells) it will cause a lot of troubles with efficiency.
Script.NET is very different, because it doesn't generate new assembly for each script - it has it's own interpreter, which is hopefully more efficient solution for such purposes. Of course, you may use Java Script ActiveX control to provide your applications with mentioned capabilities, but it has limited .NET integration.
Currently, Script.NET is a project under development. If it will have enough interest from the community, I will improve it to become "real" language. There is also an alternative solution - Python.NET.
However, Than you for the message.
|
|
|
|

|
I see what you are trying to say. But I do no think it is entirely accurate.
The performance is the strongest point of CS-Script. The same as for the other scripting solutions based on the same algorithm:
http://www.codeproject.com/dotnet/nscript.asp
http://www.codeproject.com/dotnet/DotNetScript.asp
http://www.codeproject.com/dotnet/nscripttool.asp[^]
You are absolutely right CS-Script is not an interpreter, but rather a top level Just-In-Time compiler. And this is the reason why it and the other script compilers demonstrate such a remarkable performance. They will outperform any interpreter.
The execution is so fast because for CLR the script is just an another assembly. Basically there is no difference between script execution and the execution of the fully compiled code.
However what is the price for this? Yes, there is some performance penalty. Any such compiler needs to spend some CPU time for the script compilation: 50-100 msec for a simple Foo-like script. Well, I do not know about the other compilers but CS-Script uses caching to avoid unnecessary compilation. Thus even if you have the formula associated with 5000 cells in Excel the script (implementing this formula) will be compiled and loaded only once, at the first usage. Even after restarting the host application no script will be compiled again.
I can see one scenario when an interpreter will perform better. It is if you have a few thousands small "single line" scripts and all of them are different from each other.
Interpreters like yours or IronPython have their own advantages comparing to the compilers but performance is not one of them.
Anyway, your work is interesting and I think you should continue it. Though you may also consider utilizing DLR if you want to implement truly dynamic CLR language.
Cheers
|
|
|
|

|
I agree about the performance statements of CS-Script.
However, if the intention of Script.NET is to define a simple, less-techy scripting/macro language to be embedded into some other end-user application, then I think a compromise could be made:
1. Define the Script.NET syntax to be whatever you think is most usable for your end-users, perhaps even with domain-specific constructs.
2. Interpret that language and convert it to C#, and compile it and cache it as CS-Script does.
The best of both worlds, if the intention of Script.NET is what I stated above.
If so, you may also want to create a simple editor using a colorizer I just read about in this article:
http://www.codeproject.com/useritems/GPC.asp[^]
|
|
|
|

|
Thank you very much for your ideas.
|
|
|
|

|
One of the largest disadvantages in using compiled .NET code such as CS-Script is the fact that once the assembly is loaded. It doesn't ever appear it can be unloaded. Am I correct in this thinking or has this been addressed.
In other words -
I have an app that provides an IDE to allow the end user to add some code.
CS-Script compiles the code and adds the assembly.
The user has added "bad code", so the rewrite the snippet and add it back.
CS-Script compiles the code and adss the new assembly.
I now have two assemblies with potentially the same class. If I can't unload the assembly you might as well say I have a memory leak.
There are no stupid questions, but there are a lot of inquisitive idiots.
|
|
|
|

|
Actually it is not entirely correct.
Yes what you describe is a well-known .NET limitation, however CS-Script actually allows you to unload loaded assembly. It executes assembly in the on-fly temp AppDomain and unloads whole domain after the execution.
Cheers
|
|
|
|

|
You are correct in that you cannot unload an assembly once loaded into an application domain. However, you can load and unload application domains. Therefore to unload an assembly you must keep it at arms length by putting it into a separate application domain and discarding the app domain when done with it. Biggest drawback is that all calls must cross an app domain boundary, which can have an overhead associated with it...
|
|
|
|
|
|
 |
|
|
General News Suggestion Question Bug Answer Joke Rant Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.
|
Scripting language for .NET Framework 2.0. Supports native .NET Types, Dynamic casting, Meta programming.
| Type | Article |
| Licence | CPOL |
| First Posted | 4 Oct 2007 |
| Views | 116,029 |
| Downloads | 1,585 |
| Bookmarked | 187 times |
|
|