Is there a way to use C# as a scripting language? I want users to be able to write a method body and work with objects that are passed from the main program to the script method.
And maybe is there something more universal out there? So I can support more than C#?
Check out scriptcs. Scott Hanselman has a great blog post about it here. It allows you to do scripting with C#, either by running arbitrary scripts as *.csx files, written with with your favorite text editor or by using the REPL. It also has integration with NuGet to allow you to easily pull down dependencies.
The ScriptCs.Core library can be used to host script execution in your own application, like OctopusDeploy has done.
The scripting engine is pluggable. As of now, it uses Roslyn as the C# scripting engine, but there's also work being done to use mono as an alternative. There's nothing stopping you from implementing f.ex. F# support.
To make bootstrapping of popular frameworks even easier, there's script packs that reduces the amount of code you have to write to get something running quickly.
To get you started, check out the samples repository.
Related
Summary and Question
I'm looking to generate code in C# to prevent significant repetition and wrap the Google APIs in a way like they do themselves, as stated on their .Net Client library page. Edit: Their generator is written in Python, apparently. I will continue to investigate other .Net options.
Where should I focus my attention, CodeDOM, Roslyn or something else? Should I not be considering Code Generation at all - and if so, what alternative track should I take to properly handle this situation?
Details
I am working on writing a wrapper for the Google .Net APIs to make a Google API library for PowerShell (for any and all Google APIs). I already have it working on three of the APIs, but since my project handles all of the authentication (and storage thereof) and other things like pagination, I have to basically wrap each API method call to work with my own authentication so that the user doesn't have to worry about it. This leads to a lot of repetitious coding encapsulating methods that already exist in the .Net Libraries:
public Data.Asp Get(string userKey, int codeId)
{
//I have to wrap their get method with my own using GetService(), for example
return GetService().Asps.Get(userKey, codeId).Execute();
}
Since this is all patterned on information that exists either through the Google Discovery API or through the underlying client libraries, I feel like there should be some way to generate the code and save my hands some trouble.
Some Background and Related Info
On the main page for the Google API .Net Client libraries it is stated:
The source code for the individual Google APIs is programmatically generated using the Discovery API.
I would like to do something similar, though I have no idea where to focus my time and research. I've looked up CodeDOM (and the inherent limitations), Roslyn as well as some differences between the two. I've also checked out the T4 Text Templates for Visual Studio.
To be clear, I am not looking to generate code at runtime as I would with something like Reflection, I am looking to generate bits of a library - though I'm not sure if I am looking for active or passive generation yet.
I work at Google on the .NET client libraries (among other things). Your question is pretty far reaching, but here is the general idea:
The metadata for describing "most" Google APIs is through a discovery document. That describes the methods and types the API has.
Client libraries for accessing Google's APIs then are generated, like you point out, from a Python library. (Using Django as a templating language, specifically.)
Once the code is generated for each Google API, we invoke MSBuild, package the binaries, and deploy them to NuGet.
As for your specific question about how to generate code, I would recommend you build two separate components. The first is something that will read and parse the discovery document, the second is the component that will emit the code.
For the actual code gen, here are some personal opinions:
The simplest thing to do would be to use a text-based templating language. (e.g. Django or just write your own.)
CodeDOM is an interesting choice, but probably much more difficult to use than you want. It is how Visual Studio does some of its codegen, e.g. you describe the code and CodeDOM will emit C#, VB, MC++ to match your desires. However, since you are only focusing on C#, the benefit of CodeDOM supporting multiple languages isn't useful.
Roslyn certainly is a cool, new technology, but that probably won't be of much use. I believe Roslyn has the ability to dynamically model code and round-trip the AST to disk. But that is probably overkill, since you aren't trying to build a general-purpose C# codegen solution, and instead just target generating code that matches the API discovery document.
So I would suggest a basic text-based solution for now, and see how far that can get you. If you have any other questions feel free to message me or log an issue on the GitHub issue tracker.
is it possible to invoke function which is written in Java using WCF or any class application written in C# .net
Can it be possible by using webOrb..
i can't find enough information about Java to .Net remoting..
If you want to communicate between C# and Java you have a couple of options.
The cleanest: Build a service.
This assumes you have access to the source code of both your C# component and your Java component. In the case that you want to call a method within Java, you can build a service that allows a connection from your C# client, to your Java service, and the service then executes the desired functionality, and returns a value back to the C# client. Some easy ways to do this is by building a RESTful service or using Thrift. I recommend you choose a solution similar to this one.
The most complex: Corba
Corba is a standard defined to communicate amongst different computer languages. Most mature languages have support for it, but it is a bit unusual, and the use of it has declined in favor of building service. This also assumes access to both source codes.
You'd have to independently look for the information regarding how to use Corba on both Java and C#. I would really advice against this.
The dirtiest but quickest: Execute as process and parse output
I really do NOT recommend you to do it this way unless you really have no choice. This would entail executing a Java program from within C#. This is only a good choice when you have no other option, because all you have is an executable. If that were the case, you can use the Process class to execute the external program, sending it parameters, and then reading the output. See the example mentioned here:
How do I start a process from C#?
This has many downsides though, as you'll have to think of every exceptional cause, determine the output for those cases, and then determine how to parse that output. If the program has any level of complexity, before you know it, you'll end up with hard to maintain code.
Conclusion: Build a Service
That's probably your best bet. Build a service that exposes an API that the C# client can call on.
We are using JCOBridge package: it is able to create a bidirectional invocation of Java API from C# (.NET Core/6/Framework).
The templates available on Templates was our good starting point for the needs we had. We reach the goal in few lines of code.
UPDATE 2022: the JNet project on GitHub can be used as a starting point. Another project is KNet, hosted on GitHub and based on JNet, that is a gateway for Apache Kafka Java API.
I'm trying wrap my head around all of the different scripting technologies for Windows (what are they, and which are the most common) and ultimately to figure out what type of scripting to add to my application.
I've read that with .NET 4 it's easy to make your program scriptable via dynamic languages like IronRuby and IronPython (or even VB or C# which might be more confusing for a user?) My understanding is that pre .NET 4 the way to add scripting support for your application was to make it a COM/OLE object so people could use vbscript, winbatch, shell scripts, or another scripting language (or really any language that supported COM) to control your application? What are the common scripting languages use? I've heard a lot of people talk about VB for Applications. Is that a dynamic language or a compiled language and to allow my application to be scriptable via VB for Applications would I have to support COM/OLE? I think I'm leaning towards supporting IronRuby and IronPython since it seems simple to implement support for them, but can those languages also be used to script Windows or other applications in general (and thus scripts for your application could have more features than what you laid out)? How would you go about designing your application to be scriptable?
I know that seems like a thousands questions, but really what I'm looking for is just an explanation of the scripting technologies for windows (what are the main differences, how frequently are they used) and which ones are the most common/standard to support when making your application scriptable?
Thanks in advance everyone!!
I think it depends on what you are trying to do. Are you trying to create dynamic objects in your apppool or view the values of something in your memory. If you need access to you objects then I would say maybe you could put a scripting window in your program. If you are just trying to configure certain aspects of you program you and look at adding modules to windows powershell for your admins. That seems to be what microsoft is doing for things like sharepoint and sql server. I would look up if powershell can fit your needs so that users can use the language they are confortable with and write there own scripts but if not then take a look at adding one of the dynamic languages to your app. If slashdot is to be believed today then Microsoft is not going to be persuing them as agressively.
Scrolling Game Development Kit 2 will actually compile code entered in the UI rather than interpret it as script. (It uses the C# compiler provided with the framework.) It can then run and reflect on that code at runtime. Have you considered a solution like that?
[This question is similar to this one, but I am also interested in the possibility of a sandbox.]
I am considering embedding a scripting language in my C#/.NET application and then exposing some of my application's API to the scripts. There seem to be multiple good options for this (Lua, Boo, IronPython, etc.), but are there easy options for restricting the scripting language's built-in functions from being used? For example, I do not want the scripts to be able to perform I/O except through the API that I explicitly expose, so no printing to the console, opening files, etc. Do any of these scripting languages provide an easy way to do this?
You can load te script into a different AppDomain and control the permissions of the second AppDomain.
This link should get you started:
http://blogs.msdn.com/shawnfa/archive/2005/08/08/449050.aspx
I have used Powershell as a scripting language on windows myself and found it to be very useful, and if you are familiar with .NET then its all the more easier.
Download a two page reference document here, this is all you will need to get started.
But yes you can use .NET System.IO namespace to perform IO operations via Powershell
same posted # this link
I have a little game written in C#. It uses a database as back-end. It's
a trading card game, and I wanted to implement the function of the cards as a script.
What I mean is that I essentially have an interface, ICard, which a card class implements (public class Card056: ICard) and which contains a function that is called by the game.
Now, to make the thing maintainable/moddable, I would like to have the class for each card as source code in the database and essentially compile it on first use. So when I have to add/change a card, I'll just add it to the database and tell my application to refresh, without needing any assembly deployment (especially since we would be talking about 1 assembly per card which means hundreds of assemblies).
Is that possible? Register a class from a source file and then instantiate it, etc.
ICard Cards[current] = new MyGame.CardLibrary.Card056();
Cards[current].OnEnterPlay(ref currentGameState);
The language is C# but extra bonus if it's possible to write the script in any .NET language.
Oleg Shilo's C# Script solution (at The Code Project) really is a great introduction to providing script abilities in your application.
A different approach would be to consider a language that is specifically built for scripting, such as IronRuby, IronPython, or Lua.
IronPython and IronRuby are both available today.
For a guide to embedding IronPython read
How to embed IronPython script support in your existing app in 10 easy steps.
Lua is a scripting language commonly used in games. There is a Lua compiler for .NET, available from CodePlex -- http://www.codeplex.com/Nua
That codebase is a great read if you want to learn about building a compiler in .NET.
A different angle altogether is to try PowerShell. There are numerous examples of embedding PowerShell into an application -- here's a thorough project on the topic:
Powershell Tunnel
You might be able to use IronRuby for that.
Otherwise I'd suggest you have a directory where you place precompiled assemblies. Then you could have a reference in the DB to the assembly and class, and use reflection to load the proper assemblies at runtime.
If you really want to compile at run-time you could use the CodeDOM, then you could use reflection to load the dynamic assembly. Microsoft documentation article which might help.
If you don't want to use the DLR you can use Boo (which has an interpreter) or you could consider the Script.NET (S#) project on CodePlex. With the Boo solution you can choose between compiled scripts or using the interpreter, and Boo makes a nice scripting language, has a flexible syntax and an extensible language via its open compiler architecture. Script.NET looks nice too, though, and you could easily extend that language as well as its an open source project and uses a very friendly Compiler Generator (Irony.net).
You could use any of the DLR languages, which provide a way to really easily host your own scripting platform. However, you don't have to use a scripting language for this. You could use C# and compile it with the C# code provider. As long as you load it in its own AppDomain, you can load and unload it to your heart's content.
I'd suggest using LuaInterface as it has fully implemented Lua where it appears that Nua is not complete and likely does not implement some very useful functionality (coroutines, etc).
If you want to use some of the outside prepacked Lua modules, I'd suggest using something along the lines of 1.5.x as opposed to the 2.x series that builds fully managed code and cannot expose the necessary C API.
I'm using LuaInterface1.3 + Lua 5.0 for a NET 1.1 application.
The issue with Boo is that every time you parse/compile/eval your code on the fly, it creates a set of boo classes so you will get memory leaks.
Lua in the other hand, does not do that, so it's very very stable and works wonderful (I can pass objects from C# to Lua and backwards).
So far I haven't put it in PROD yet, but seems very promising.
I did have memory leaks issues in PROD using LuaInterface + Lua 5.0, therefore I used Lua 5.2 and linked directly into C# with DllImport. The memory leaks were inside the LuaInterface library.
Lua 5.2: from http://luabinaries.sourceforge.net and http://sourceforge.net/projects/luabinaries/files/5.2/Windows%20Libraries/Dynamic/lua-5.2_Win32_dll7_lib.zip/download
Once I did this, all my memory leaks were gone and the application was very stable.
The main application that my division sells does something very similar to provide client customisations (which means that I can't post any source). We have a C# application that loads dynamic VB.NET scripts (although any .NET language could be easily supported - VB was chosen because the customisation team came from an ASP background).
Using .NET's CodeDom we compile the scripts from the database, using the VB CodeDomProvider (annoyingly it defaults to .NET 2, if you want to support 3.5 features you need to pass a dictionary with "CompilerVersion" = "v3.5" to its constructor). Use the CodeDomProvider.CompileAssemblyFromSource method to compile it (you can pass settings to force it to compile in memory only.
This would result in hundreds of assemblies in memory, but you could put all the dynamic classes' code together into a single assembly, and recompile the whole lot when any change. This has the advantage that you could add a flag to compile on disk with a PDB for when you're testing, allowing you to debug through the dynamic code.
Yes, I thought about that, but I soon figured out that another Domain-Specific-Language (DSL) would be a bit too much.
Essentially, they need to interact with my gamestate in possibly unpredictable ways. For example, a card could have a rule "When this cards enter play, all your undead minions gain +3 attack against flying enemies, except when the enemy is blessed". As trading card games are turn based, the GameState Manager will fire OnStageX events and let the cards modify other cards or the GameState in whatever way the card needs.
If I try to create a DSL, I have to implement a rather large feature set and possibly constantly update it, which shifts the maintenance work to another part without actually removing it.
That's why I wanted to stay with a "real" .NET language to essentially be able to just fire the event and let the card manipulate the gamestate in whatever way (within the limits of the code access security).
The next version of .NET (5.0?) has had a lot of talk about opening the "compiler as a service" which would make things like direct script evaluation possible.