This release is coming very soon after the 0.4.0. It doesn’t mean that I’m going to increase my release cycle, it’s just that I have some new features that I’d like to share with you and there were things in the 0.4.0 that I wasn’t satisfied with.
The following subsections describe the new features of scriptcs.rebus 0.5.0.
New API for scriptcs.rebus.hosting
In 0.4.0 I introduced the hosting feature in scriptcs.rebus. With this feature you can extend any standard .Net application with new functionality using scriptcs. You would send a custom script to a host application, which would then be able to compile the script and execute this inside the host process. Now, in 0.4.0 you would send the script like this:
This would send the script inside the
start.csx to a host for execution. And, if you would need to download and reference a NuGet package, you would do it like this:
This would download and reference the Mongo C# driver and execute the
start.csx script inside the host application. This was my initial and, admitted, pretty naive implementation. So, when I wanted to introduce the use of the Mono compiler inside the hosted application, I ran into some issues. You can read all about my endeavours with scriptcs.hosting here.
So, in 0.5.0 I’ve changed the API, so now if you want to send a script you go like this:
And a script file:
This is all just semantics, so why the change? Well, I wanted to add a bunch of additional options, so therefore I needed a fluent api for this. In the following sections I’ll shortly describe them.
Add a Local Reference to Host Executed Script
If you want to reference a local assembly to be used in your script, this could be an assembly that is part of the host application, you can add the following option:
Now, you can reference more local assemblies, just add another
Download and Reference a NuGet Package for Host Executed Script
So if your script needs a NuGet package to extend the host, you can specify these using the
AddFromNuGet() like this:
Again, you can add multiple
AddFromNuGet() to the configuration.
Importing a Namespace for a Host Executed Script
So, imagine we now have downloaded a NuGet package or referenced a local assembly, then to make it available for the script, you need to specify in which namespace to find the type you wanna use:
This would download and reference the Mongo C# driver and make the MongoDB.Bson namespace available to the script for execution.
Using the Mono Compiler on the Host
Since the current release of Roslyn, does not support things like the
dynamic keyword or
async/await, it might be handy to be able to use the Mono compiler on the host:
Now the Mono compiler is set as execution engine, the script will be compiled. A scenario like this could also be relevant when doing cross-platform development.
Logging Inside the Host
In some cases it might be great to see some debugging output in the host console.
This sets the loglevel to Debug, instead of Info which is default. This feature is only relevant in a limited number of cases where the host is a console application.
Using Script Packs Inside a Host
Script packs are really just NuGet packages used for hiding boilerplate code of common frameworks. Therefore, if you download and reference a script pack, it will be made available to the script without any further.
That’s all there is to 0.5.0. So throw me comment, either below or on Twitter.