The last month or so I’ve been busy on putting the pieces together for the latest release of ScriptCs.Rebus. I’m very proud of what I managed to put into this release.
This is the fourth release of my little scripting tool, and this post will focus on what’s new in version 0.4.0, so if your new to ScriptCs.Rebus, I urge you to read my other posts.
What’s New
Some minor bug fixes, the major features of this release is support for Azure Service Bus and scripted host execution.
One other major change in this release is that I’ve split ScriptCs.Rebus into separate dependencies. This will be a breaking change for existing users, and you have my apologies for that. When adding Azure Service Bus, it occurred to me that it didn’t make sense to distribute ScriptCs.Rebus with dependencies for all transport options, when you’re only using a single one. So therefore from version 0.4.0 ScriptCs.Rebus spans the following NuGet packages:
Support for Azure Service Bus
To get started using Azure Service Bus, you need to install the script pack:
And you would also need to create a service bus on Azure.
As the addition of RabbitMQ in version 0.3.0, I’ve continued the original design for configuration:
A message containing a string is now sent to the Azure service bus specified in the connection string, and added to the queue given in the first parameter. The connectionstring must be the connectionstring of the service bus, and not the actual queue. Receiving a message follows the design of the MSMQ and RabbitMQ:
Hosting
Now this a feature I’m really proud of. Hosting is a vital, yet powerful feature in ScriptCs. The idea is that you can host ScriptCs inside any standard .Net application and that way execute code inside the host. This gave me the idea to create a ScriptCs.Rebus hosting feature for executing scripts received over any of the support buses. I have been playing around with ScriptCs.Hosting before, but was pretty unsure were to start. I therefore got in contact with Glenn Block, with whom I had some discussions over the idea. The result is ScriptCs.Rebus.Hosting.
First of you need to reference the NuGet package from your application. Go to the package manager console:
This will provide with a number of dependencies, but in essence it is the complete ScriptCs that you now have a reference to and can use to execute C# code. The pieces that ScriptCs.Rebus.Hosting delivers is a message handler capable of executing a script. It can even download and reference extra NuGet packages required by your script. I now this sounds strange and complex, but I believe I’ve developed a rather simple and powerful implementation.
There are two options to go for when you wanna execute scripts, received over any supported bus technology using Rebus, in your application.
Existing Rebus Infrastructure
If your application is already using one of the supported bus technologies with Rebus, just hook in the supplied message handler. How this is done, depends on how you have configured Rebus. But the ScriptHandler class implements the standard IHandleMessages<T> interface in Rebus. So all you need to do is register the message handler to the DI container you have configured for Rebus in your application.
No Rebus Infrastructure
If your application does not use any bus infrastructure and you would like to extend its functionality using scripts, you can get going using the following simple configuration:
That’s it! Your application is now ready to receive scripts send over MSMQ. It is advisable to configure the bus in a bootstrapper or application entry point. The Start() can be deferred to other parts of the application.
Should you wanna go for RabbitMQ or Azure Service Bus, just change the first line. See the README. When using RabbitMQ or Azure Service Bus, you would need to reference either the ScriptCs.Rebus.RabbitMQ or ScriptCs.Rebus.AzureServiceBus script packs as well.
Sending A Script
Now that you have a script-aware application, lets start sending some scripts. You can send scripts from the source of your choice. You can go simple and send it from the ScriptCs REPL:
This would send this simple script to the host, which would then execute this. If the bus is not started in the hosting application, the script will wait in the queue, and be executed when the bus is started. Standard messaging stuff. You can also send a script from another application:
Sometimes you just don’t wanna write your scripts in the REPL or inline in the sending application. You can therefore create a script file, in your favorite editor, and send it for execution in the host. From the REPL this would look like this:
The script file will now be send over the bus and executed in the hosting application. You can do the same from another application.
Additional NuGet Packages
If executing C# scripts inside a host application cannot make your day, how about downloading and referencing additional NuGet packages inside your host application, and executing a script using them.
If your script is going to require additional NuGet packages, which is not already referenced by the host, you can supply them when sending the script:
If the LiteGuard Nuget package is not already downloaded and referenced in the hosting application, ScriptCs.Rebus.Hosting will download and reference it, so you can use it your script. Using LiteGuard is just an example.
Please feel free to either give me a shout on Twitter or on GitHub with feedback.