scriptcs gets a REPL!

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.

clip_image001

And then we have pretty error handling.

clip_image002

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 | 8 Comments

Debugging node.js errors in Windows Azure

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:

Screen Shot 2013-03-31 at 8.21.37 PM

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.

Screen Shot 2013-03-31 at 8.29.21 PM

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.

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 I see the following:

Screen Shot 2013-03-31 at 8.34.14 PM

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.

Screen Shot 2013-03-31 at 8.37.58 PM

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.

Screen Shot 2013-03-31 at 8.40.42 PM

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

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 thought 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.

Screen Shot 2013-03-31 at 5.35.57 PM

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.

MP900402894[1]

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

This will list out my websites in json format.

Object command style

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

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

Piping

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

  1. npm install azure-scripty
  2. go check the README.
  3. 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

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

scriptcs – Living on the edge in C# without a project on the wings of Roslyn and Nuget

MP900430605[1] 

Disclaimer: I am not the first person to create a tool for C# scripting. There are a long list of projects from too many people to name, and I respect all of them :-) A big part of why I did this was also to mess with Roslyn.

Learnings from node

For the past 18 months I’ve been living mostly in text editors and script getting fully absorbed in node.js. Recently I started to think a lot about my C# development experience and if there are things I could bring back from my learning’s with node / JavaScript

  • No projects, just script- One of the things I love about node.js is you don’t need a project. You can just jump in a folder start creating js files and go to town.
  • No IDE requirement, you can just use a text editor.
  • Packages over assemblies – In node, when you want to get something you use npm to download the packages.It’s super simple. You just have your app and your local node_modules folder and you are good to go.
  • No compilation – This is a big one. With node, I just run node.exe and my app and it works. I don’t have to first create an executable to run, I just run.

On first glance it might seem like this is just oil and water with C#.

Thanks to Roslyn and Nuget however I no longer think that’s the case.

What is Roslyn?

image 

Roslyn is a compiler as a service. It gives you an API that lets you compile and analyze code on the fly. Additionally it gives you hooks to dynamically refactor and generate code. Beyond that it also includes really powerful scripting support allowing you to author applications and components as loose C# scripts. You don’t need a class if you don’t want one and you don’t need to compile. And you don’t need to use Visual Studio, you can host Roslyn in your own applications and components and it’s even got nuget packages.. You can read more on Roslyn at MSDN or in a nice post from Filip on Roslyn and Web API

Roslyn is a breath of fresh air in terms of it’s simplicity. If you have worked with the existing horrendous mechanisms for doing this like the Codedom you are going to love Roslyn. You can literally be up and running with Roslyn having it compile scripts for you in a matter of minutes.

How does Roslyn help?

I can cross off three bullets :-)

  • No projects, just script- One of the things I love about node.js is you don’t need a project. You can just jump in a folder start creating js files and go to town.
  • No IDE requirement, you can just use a text editor.
  • Packages over assemblies – In node, when you want to get something you use npm to download the packages.It’s super simple. You just have your app and your local node_modules folder and you are good to go.
  • No compilation – This is a big one. With node, I just run node.exe and my app and it works. I don’t have to first create an executable to run, I just run.

Now yes it does compile, but that’s all taken care of for me, I don’t have to think about it.

Packages vs Assemblies

For the last bullet I looked to nuget. The nuget command line provides an easy way to install packages right from the command line into the same folder as a set of scripts. However, the challenge is how to make those scripts see those packages? Today Nuget works great with a csproj and within Visual Studio or using MS Build. But what if you don’t have Visual Studio or a csproj? Well when you install packages using the cmd line you get folders for each package that at some level actually do contain binaries. So, if you can find those binaries and get them loaded up into Rosyln, you are golden. Yes this doesn’t get rid of assemblies, but I don’t have to manage them individually, I just install packages.

  • Packages over assemblies – In node, when you want to get something you use npm to download the packages.It’s super simple. You just have your app and your local node_modules folder and you are good to go.

Roslyn + Nuget = scriptcs

Having crossed off all my bullets, I then decided to spike a little with Roslyn and out came Scriptcs: https://github.com/glennblock/scriptcs

scriptcs is a little command line tool which lets you have the following work flow.

  • You author your “app” as a .csx file or csharp script in your favorite editor. There’s no project.
  • You add dependencies to your app by simply installing nuget packages from the command line. By convention the dlls within those packages will be loaded up. No need for references as the idea is if it’s there you want it.
  • You add GAC references or other dll references (not nuget packages) by using the “r:” Roslyn syntax, i.e.”r: System.Net”.
  • You run your app using “scriptcs” passing the csx file.

For example here is a snippet of setting up a web api host.

Back to reality, though the future looks bright.

MP900403166[1]

At this point I would say this is just an experiment. I am not claiming you can build an enterprise app with this or anything like that. I am using this more as an exploration to understand what a c# script experience from outside VS could look like.

From here there’s a lot more places to go. One would be allowing you to have includes of other csx files as you probably don’t want your whole app in a single file! Beyond that Roslyn offers a ton of rewriting, AST analysis or even auto-refactoring capabilities that I am sure can be leveraged in scriptcs but are not.

Seeing this definitely makes me excited about where things can go in the future. I’d love to hear your thoughts.

Posted in coding, rosyln | 13 Comments