Toying around with Visual Studio Monaco on Windows Azure … some side dishes

050313_1311_Didyouknowh1.png2,5 months ago MSFT released Visual Studio Online to the masses (see my first look blogpost from 13/11/13 at it here ). It’s a great system and it works like a charm, but there’s a few things you need to know besides just the basics.

It’s an extension Jim, but not as we know it.

First things first, the foundation and architecture. Well actually when you’re using Monaco on of your websites, you’re actually using … well … your website. Monaco is installed as a Private Website extension totally living in the same sandbox environment as your website only with a different end-point.

When we take a look on the structure it will become more clear:

As you can see both the website and the Monaco site extension point to the same inetpub root on the PaaS IIS role. (Yes, websites do run on Windows Azure webroles). The only difference is that the VSO does editing and the entry point on website does runtime execution.

Knowing what the structure is of this this technology then something should slip to mind. Since it runs on the same node and workspace, you should realize that, when you would activate and use this a lot, it comes with a cost.

Because it runs on the same PaaS role, it will also use its compute and bandwidth capabilities. Compilation will be accumulated with your web calling compute hours on your website role. This means that, when for instance, running free model websites your website might be locked from time to time. So this is important enough to know and realize.

How they’ve build it is actually quite cool. The total solution Node.JS bases and consists out of a little more than 200.000 lines of TypeScript code, which gets compiled to JavaScript. So the entire thing is running client side/in the browser. For those who pay close attention: yes it is based on the same solution as is used for “Napa”, TFS Online, SkyDrive, Windows Azure Mobile Services, and so on and so …

Fast responsiveness during coding, semantic references, AST (Abstract Syntax Tree) running in the browser, etc. … are all being generated through TypeScript in the browser. Giving you flexibility and performance at your fingertips.

As stated, it’s based on Node.Js and following technologies have been integrated/used for developing the environment(s) in the back-end:

As you can see a nice fair set of tools and technologies used for bringing you a rich environment.

Crouching Tiger, Hidden Dragon.

Being aware of all the goodness Monaco hides let’s take a look at some non-conventional scenario’s. And by non-conventional I do mean scenario’s that it wasn’t perhaps even meant to be used for.

  1. I got the Power(Shell)

    Since we are running in a windows environment, one could start looking for the underlying technologies. One of the more important things in Windows today is PowerShell. Does it exist? Typing powrshell doesn’t seem to do much, but when typing help we do see there’s a powershell entry:

    But then again, it’s not a real life console as we know it.

    So let’s try something basic and try to get all the processes from the machine (s). I add a new file to the explorer tree and edit it with the line get-process

    I then enter the command ps powershell.ps1 in the console and …. Tattaaa:

    All the running processes are showing.

    I can even get all the variable information out of it by using get-variable:

    Or the PS version :

    BUUUUT no services … :

    This will probably have to do with the sandboxing (and can probably be used as proof too I think).

    Then again some powerfull info can still be gained from dir‘ing the env: psdrive which shows us that we are running on a Red Dog (the old/original Windows Azure Codename) machine and what kind of machine we’re running it on in shared mode

    Then of course we could use this power to create some stuff also, like webpages with that info and much much more. I haven’t found out which cmdlets are able to run and which ones not. But I think you could put some good use to the ps shell somehow.

  2. The Cloud Atlas … aka azure-cli

    Another thing we have available to this environment is npm (so it seems, when we run help from the console). Now, I don’t know about you, but when you say npm to me the first thing that jumps to mind is … you guessed it! Windows Azure Xplat Client Tools J !!! Now I got you probably thinking “wait, you’re not saying you want to manage the cloud … from the cloud …. ?” Yes I actually do want to do that: imagine git + npm + xplat tools = continuous availability of all your management scripts ! no need to have a device with all tools installed: you just need a browser. Yes but you also just can use the portal then … well not quite true, because now you can use your onsite created scripts … EVERYWHERE (even from a smartphone!)

    So let’s see if we can pull this one off :

    Well not with the –g switch (sandbox) but we can do it without. And as you can see it created me all my node tools in a separate folder inside my website:

    It installed allright , but does it work?

    It seems so now, doesn’t it?

    So the only thing missing a publishing settingsfile or an account login. Since the Azure-cli tools don’t support the account login yet, we need to go for a settings file. I guess launching a browser window from an emulated console inside a browser would be impossible, but I gave it a try anyway:

    No luck there, so I just dl’ed myself a fresh one from my own stack and dragged it inside my file explorer pane in Monaco:

    Let’s try to import the settings:

    This means I can access my Windows Azure Assets, right? Let’s try for something nog websites related:

    Cool J, can I do more?

    Let’s stop a VM

    Do note: CASE SENSITIVE ;-)

    WORD OF ADVICE : when doing the above operations: DO NOT FORGET TO DELETE YOUR .publishsettings! it’s a precious thing!

[UPDATED/ADDED 28-01-2014] The tale of two Git-ies …

When considering using VSO Monaco, try only to use it with DEV or more static WebPages and not in direct measures of using it in heavy production websites. Try to set up an ALM stream from your sources just a s you would in any other situation. The easiest way to achieve this is to activate the new Staging Preview on websites, which will actually help you on this matter (in the easiest way). How to proceed?

  1. Initiate a new website and activate VSO Monaco on this one. This site will function as your DEV area
  2. clone or initiate (depending on what you already have of course) a Git repo.
    DO NOTE: this is not to be confound with publish from sourcecontrol, this has to be seen as a LOCAL REPO! so do it through the VSO MONACO INTERFACE.
    Once that’s done and you have a stable solution, you can proceed to the next step in the flow
  3. initiate a second Website (create a quick one, without anything)
  4. activate the Staging Preview on this one.
    DO NOTE: when doing this you’ll need a standard mode website to achieve this, your dev site can still be in free mode (but consider the accompanying cost remark made earlier)
  5. once that’s done, open the staged site and choose to deploy from source control on that one and activate your earlier created git repo on this one.
  6. when in place you can now do a VIP swap when finished in Staging when neededHere’s a schematic of the flow :
    If you want more info on the underlying  and a more deep ALM thought on the thing take a look at the Monaco Blog site :

As you can see VSO Monaco is not limited to coding alone, it even makes a great environment for doing some perhaps continuously available devops stuff. As with many thing Azure one should think outside of the box (and a big box it is indeed). Monaco is a standard tool but one you can (ab)use for your needs. Especially when you know that the entire environment is sandboxed and totally locked down for your privacy.

Happy tinkering!

Yours truly,



6 thoughts on “Toying around with Visual Studio Monaco on Windows Azure … some side dishes

  1. Great blog post. With regard to the accumulated costs issue “This means that, when for instance, running free mode websites your website might be locked from time to time. ” This can indeed happen and for this reason we recommend to create a development site separate from the production site when doing in-depth development. This set-up is described in this blog post:

    • that is indeed also my reccomendation, hence I’ll update the post and refer to your blog too, in order to make DEV TEST PROD Scenario’s more clear, thanks for the comment and for reminding me!

  2. Pingback: Monday, January 27, 2014 on #WindowsAzure | Alexandre Brisebois

  3. Pingback: Tuesday, January 28, 2014 on #WindowsAzure | Alexandre Brisebois

  4. Pingback: Monday, January 27, 2014 on #WindowsAzure | TGS Partners

  5. Pingback: Tuesday, January 28, 2014 on #WindowsAzure | TGS Partners

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s