Glenn Block

Scripting ease with Script Packs

Posted on May 14, 2013 by Glenn Block

Script Packs are a really cool extensibility point we added into scriptcs. A pack delivers a bundle of functionality that makes frameworks more palatable to consume from script. They are available as nuget packages making them very easy to consume.

For example, if you look at our Web API sample, you’ll see there’s a bunch of friction if you just try to get Web Api working from scratch.

You need to add using statements for each namespace you want to use. This is a lot more painful than one might think when you don’t have intellisense.
You need to configure web API, this involves creating a host, defining default routes etc. Adding lots of object creation and such starts to make the script pretty hairy. Not impossible, but painful when there’s no template.
You need to teach Web Api how to resolve controllers in script by implementing a custom controller resolver.

Now pull in the Web Api script pack (scriptcs –install scriptcs.webapi) using the Require<WebApi>() function and your boiler plate code evaporates to this:

    
          public class TestController : ApiController {
  public string Get() {
    return "Hello world!";
  }
}
 
var webApi = Require<WebApi>();
var server = webApi.CreateServer("http://localhost:8080");
server.OpenAsync().Wait();
 
Console.WriteLine("Listening...");
Console.ReadKey();
server.CloseAsync().Wait();

          view raw
          gistfile1.cs
          This Gist brought to you by GitHub.

The script pack does all of the following to make the experience better:

Removes the need for using statements for common namespaces. The script pack provides those which is why you don’t have to add the web api namespaces in your example above.
Adds dll and nuget package references that bring the dependencies the framework needs.
Removes general boilerplate code. In the previous sample you need to create a host, define routes etc as I mentioned. In this case the script pack creates the host for you and configure with the default routes. You can customize if you need to.
Provide APIs to fill gaps that prevent the framework from working well in script / supporting dynamically emitted assemblies. The Web Api script pack brings in and configures a custom controller resolver for you.

We’re just getting started with the work we’ve done with script packs, but they are a really nice extensibility point and really take advantage of nuget as a delivery mechanism. The community has been rising to the occasion and building out quite the gallery as well.

There’s some great posts about script packs covering topics like how to build them or even use them from the REPL that you should really check out.

Have fun exploring the new world of scripting in C# with scriptcs!

Posted in c#, scriptcs | Leave a comment

scriptcs gets a REPL!

Posted on May 7, 2013 by Glenn Block

Hello c# scripters!

Before you go further, if you are wondering what all the scriptcs hype is about please check out Scott Hanselman’s great post and his new Tekpub video.

Last few days I’ve been working on a new REPL experience for scriptcs and now it’s in! REPLs are nothing new to dynamic languages but they have not really been available in C# with one exception, Mono has a great REPL. Roslyn introduces the Roslyn interactive window in VS which is also a REPL which runs in the editor.

This REPL is different than both in that it is specific for scriptcs, and like the rest of the scriptcs experience, there’ s no IDE required. Basically it combines the goodness of scriptcs (nuget) with an interactive experience. You can just install some nuget packages and type code which instantly executes. For example imagine just pulling in HttpClient and then just doing some http requests!

Below you can see I am installing the mongo nuget package. Then running scriptcs by itself and typing in some simple code to work with the package.

And then we have pretty error handling.

Thanks to the Roslyn team’s efforts layering a REPL on top was AMAZINGLY easy. The REPL part itself was like 15 lines of code! And thanks to the nuget team for even making this a remote possibility through having an awesome package ecosystem. I look forward to ALSO seeing the mono version soon

If you wanna try it, you can grab the latest from github at http://github.com/scriptcs/scriptcs in the dev branch.

It will also be on our chocolately nightly builds tomorrow: http://www.myget.org/F/scriptcsnightly. It should be on our public feed very soon there after.

Posted in scriptcs | 3 Comments

Debugging node.js errors in Windows Azure

Posted on April 1, 2013 by Glenn Block

A common problem you might encounter in Windows Azure is seeing a big old “The page cannot be displayed” page due to an error occurring in your azure-deployed node app.

If you haven’t seen it, it looks exactly like this:

The reason this is happening is because by default we don’t allow errors to propagate back to the user. This is in order to prevent you publishing to production and leaking details of your system.

Let’s assume I just published a simple express app, but I made an error. Below you can see that instead of requiring winston, I required win$ton.

When I publish, I’ll see the page cannot be displayed error.

iisnode.yml to the rescue

To find out what is going on, you can enable displaying errors using our YAML configuration file otherwise known as iisnode.yml. If you use our azure-cli tool, and create a site in a directory where there is a node app, then we automatically create it for you. If not, you can create one really easy with any text editor. The entries you need to put in the file / update are below.

    
          loggingEnabled: true
devErrorsEnabled: true

view raw iisnode.yml This Gist brought to you by GitHub.

Once you save that file, go republish to Windows Azure. If the file did not exist and this is an Azure Website, do an “azure site restart”. if the file already existed, you won’t need to do anything.

Now with debugger errors enabled, when I see the following:

Bingo!

Don’t go to production this way, but DO use tail for websites.

Make sure to disable debugger errors when you go to production. You can leave logging enabled however, because another command you can still use is “azure site log tail” which will stream logs directly to your console realtime. Also if you are a cloud service, you can remote in to view the logs written locally.

Using “azure site log tail” watch what happens when I refresh the page.

azure-log tail has many more uses. You can use it to capture any log output that your applications give you in a realtime manner. For example here’s a screenshot of me tailing an app using socket.io and Service Bus in Azure.

Yes it is awesome!

PS: Today “tail” works only for node apps, but that is going to change VERY shortly.

Posted in azure, cli, node.js | Leave a comment

azure-scripty – Azure CLI scripting made even easier

Posted on April 1, 2013 by Glenn Block

Note: At any time if you want to just get it and jump in, “npm install azure-scripty” and start scripting

If you are using our azure-cli then you might have though of creating automation scripts to package up common tasks. A while ago I posted on how you can achieve some script-ability just using bash tools. Basically the techniques I listed there involve piping text from command to command and using tools like grep and awk to parse the results in order to feed to the next command.

It turns out there’s another way, and one that is much closer to the kind of fidelity you an achieve with Powershell. Sound interesting? keep reading. It turns out the majority (like 99%) of our cmds can return JSON objects if you apply the –json switch.

For example if I do “azure site list –json” here’s what I get.

That means that I can take that result and parse it into a JSON object which I can then easily manipulate. Potentially I could even pipe results in from one cmd to the other. I could even imagine being able to define cmds as JSON objects so that I could script out my tasks in a more object friendly fashion. I could then wrap that all up in a nice pretty box to be used by myself or others.

And that is what azure-scripty is about. (Kudos to @JpScripter for reminding me I need to post.)

azure-scripty gives you a JSON oriented API that you can use within a node script for automation tasks. It lets you combine the power of raw node with the capabilities of our azure-cli. One thing that is also really nice is it leverages the knowledge you already have of the CLI. As it says on the github page, “if you know the CLI you know scripty.”

azure-scripty offers you the following:

Works anywhere node works i.e. Windows, Linux, Mac, Nodecopter
Author using pure string command or JSON object command styles.
Uses the standard node callback model
Batching multiple commands together.
Piping results from one command to the other

Here’s a few examples to give you an idea:

String command style

    
          var scripty = require('azure-scripty');
scripty.invoke('site list', function(err, results) {
  console.log("my sites\n" + results);
});

          view raw
          gistfile1.js
          This Gist brought to you by GitHub.

This will list out my websites in json format.

Object command style

    
          var scripty = require('azure-scripty');
cmd = {
  command: 'mobile create',
  positional: ['mymobileservice', 'sqladmin', 'myP@ssw0rd!'],
  sqlServer: 'VMF1ASD',
  sqlDb: 'mydb'
};
scripty.invoke(cmd, function() {});

          view raw
          gistfile1.js
          This Gist brought to you by GitHub.

This sample creates a new mobile service using the object oriented style. Notice you can pass fixed position args, with all other named args being by convention.

Batching

    
      
        
        
          var scripty = require('azure-scripty');
cmds = [
  {
    command: 'mobile create',
    positional: ['mymobileservice', 'sqladmin', 'myP@ssw0rd!'],
    sqlServer: 'VMF1ASD',
    sqlDb: 'mydb'
  },
  {
    command: 'site create',
    positional: ['site1'],
    location: '"West US"',
    subscription: 'foobar'
    git:true
  }
]
 
scripty.invoke(cmds, function() {});

        
      

  

          view raw
          gistfile1.js
          This Gist brought to you by GitHub.
        

This sample shows creating a web site and a mobile service using the object oriented style.

Piping

    
          var scripty = require('azure-scripty');
scripty.invoke(['site list', 'site stop :Name'], function(){});

          view raw
          gistfile1.js
          This Gist brought to you by GitHub.

One of my favorites. This example shows using piping to pipe the list of sites into the stop command. Notice that :Name, that’s plugging in the Name parameter from the returned site.

Get it and please give feedback

npm install azure-scripty
go check the README.
Start scripting!

Looking forward to your feedback and your contributions!

Posted in azure, node.js | 1 Comment

Node 0.10.x compat issues with the Azure SDK and CLI

Posted on March 18, 2013 by Glenn Block

Recently the node blog announced that node 0.10 has shipped. This release includes a bunch of exciting improvements to node core around several areas including streams, domains and performance.

As soon as it shipped we started to get reports of issues using our SDK and CLI. We’ve investigated this and uncovered that there are some things we need to fix. In the meanwhile, node 0.10.x is not currently supported. We’d ask everyone using our SDK and CLI to stick to node 0.8.x for the time being.

If you are using our Mac or Windows installers you should be fine as they each include private copies of node with working versions.

We are on top of this and will be working on this in our next sprint. We’ll keep you posted and let you know as soon as we have it working which we expect to be very soon.

Thanks for your understanding and sorry for any inconvenience this has caused.

Posted in azure, node, node.js | 1 Comment