UPDATE 6/1/2013: As of June 1, 2013, the licensing has been updated so you can run all of your MSDN software except Windows client and Windows Server on Azure. This is outlined in the licensing whitepaper. I’ll leave the below discussion in place for posterity but the latest update has rendered it irrelevant.

I was sitting at the car repair place on Saturday with my Surface RT thinking it’d be nice to have a Visual Studio instance to tinker with. Given I have an MSDN subscription that comes with a free Azure VM and Visual Studio, it made sense to me that I could just set up the VM with Visual Studio and play on that.

It doesn’t look like licensing allows you to do that.

I’m still waiting to hear something somewhat “official” from Barry Dorrans (@blowdart) but Mark Brown (@markjbrown, an Azure community person) says you can’t do that, and my research agrees with Mark. Here’s what I’ve put together:

The Azure licensing FAQ says you can’t install Windows 7 or Office in Azure because they’re classified as “Desktop Applications” and can’t run on virtual machines. There’s also a question about running MSDN licensed items in the cloud indicating you can’t extend your rights there. I’ll copy/paste those here:

Q: Can customers run Microsoft Office and Windows 7 Client on Virtual Machines? A: No.  Under the Microsoft Product Usage Rights (PUR), Office and Windows 7 are not licensed to run on Virtual Machines.  In particular, Microsoft Office is classified in the PUR as “Desktop Applications”, which is not included in Licensing Mobility.

More information is available at the site for Microsoft Product Use Rights.

Q: Can a customer extend their MSDN use rights to the cloud? A: No, the software licensed under MSDN subscriptions is not for use in cloud environments.  However, most MSDN subscribers are entitled to a significant amount of Windows Azure services as a benefit of their subscription and can use these benefits to run instances of Windows Server on the Windows Azure IaaS or to run Windows Azure PaaS services.  For details on the amount of Windows Azure services included with MSDN subscriptions, please see http://www.windowsazure.com/en-us/pricing/member-offers/msdn-benefits/.

To run a VM including Microsoft server software such as SharePoint Server, Exchange Server, SQL Server, or BizTalk Server in a Windows Azure VM, an MSDN subscriber could use their Windows Azure benefits to cover the usage of the Windows Azure services and Windows Server running in the VM, then use license mobility on server licenses that their organization has covered under Software Assurance in order to run instances of the server software in the VM.

Following that Product Use Rights link, you can get the latest product list document and you’ll see that Visual Studio is also classified as a “Desktop Application,” so I have to assume it’s considered in the same way Office and Windows 7 are.

UPDATE 2/20/2013: Looking at the Visual Studio 2012 and MSDN Licensing White Paper, there’s this section:

When Virtual Environments Require a Separate License

If a physical machine running one or more virtual machines is used entirely for development and test, then the operating system used on the physical host system can be MSDN software. However, if the physical machine or any of the VMs hosted on that physical system are used for other purposes, then both the operating system within the VM and the operating system for the physical host must be licensed separately. The same holds true for other software used on the system—for example, Microsoft SQL Server obtained as MSDN software can only be used to design, develop, test, and demonstrate your programs.

I can see how Azure is a cloudy (haha) area here because the physical hardware backing it is hosting multiple VMs - some are production sites, some are dev/test.

It also appears there is some discrepancy in interpretation of whether or not you can use Windows 7 on a VM. It looks like if you have certain licenses for it, you actually can run Windows 7 in a VM.

This makes me re-think whether or not you really can use Visual Studio in the cloud. I’m less certain than I was when I posted the original article

From a personal standpoint, if you can’t use VS in the cloud… I think that’s dumb. From a business standpoint, if a company wanted to pay for Azure VM resources to host all of their dev machines or something in the cloud so you can stamp them out easily, scale up or down… why not? Sounds like a missed opportunity to me. But even if you ignore that, I feel like Visual Studio should be a kind of “special case” app. Yeah, it’s a desktop app, but there are different reasons you’d want to install it in places like Azure so I don’t know why you’d restrict it. Maybe they’ll change it in the future. Maybe they’ll extend MSDN licensing to allow for that special case or something. I hope they do. Until then… looks like I don’t get to dev on my Surface RT unless I want to set up the hosting for that myself… on a real, physical machine.

Standard disclaimers apply here. Doubly so because we’re in legal territory. I’m no lawyer, and I don’t know if you or your company negotiated different licensing. I don’t know about all the different crazy combinations of licensing out there and there’s a lot of craziness around licensing you need to be aware of to be fully compliant. For me, I’d recommend erring on the side of caution - if you don’t know for sure, don’t do it. Check with your Microsoft rep or company or whatever to find out for sure. I’m just providing the above research to show you what I found and maybe help inform you. If it turns out I’m wrong… let me know (and provide some docs I can refer to). I’ll be happy to update the article.

I’ve got Sublime Text 2 and I love it. (I even have a package I wrote myself for it.)

I wanted to get JSHint going in it and I saw that there was a nice JSHint package… but then I found SublimeLinter, which seems to be the King of Sublime Text Linting Packages. It basically can run any lint for any program type and gives a nice inline highlighting for errors. Very cool, very flexible.

And very hard to figure out all the steps needed to get JSHint up and running properly on a clean system. So here’s what you do:

1. If you don’t already have it,****install node.js**.** JSHint comes packaged with SublimeLinter and uses node.js to run it.
2. If you haven’t already done it,**install Package Control for Sublime Text. Restart Sublime Text after you do that.
3. Open the Sublime Text command palette (Tools –> Command Palette) and type “Install Package” in the palette to get the Package Control install dialog.
4. Type “SublimeLinter” in the package list to find the SublimeLinter package.Install that.
5. Restart Sublime Text. This isn’t always strictly necessary, but sometimes (like when installing node.js) stuff in the environment changes and you need Sublime Text to refresh that.
6. Optional: Set your JSHint user options by going to Preferences –> Package Settings –> SublimeLinter –> Settings - User. It’s a blank file, so you may want to look at the default settings to get a copy/paste start.

Now when you open a JavaScript file, you’ll see highlighting on lines with problems. JSHint runs in the background and updates the highlighting with problem lines. To figure out the problem, put your cursor on the line and look in the status bar at the bottom of Sublime Text.

For JSHint options, I’m using the same ones as jQuery. My user SublimeLinter.sublime-settings is below.

    {
        "jshint_options":
        {
            "curly": true,
            "expr": true,
            "newcap": false,
            "quotmark": "double",
            "regexdash": true,
            "trailing": true,
            "undef": true,
            "unused": true,
            "maxerr": 100,

            "eqnull": true,
            "evil": true,
            "sub": true,

            "browser": true,
            "wsh": true,

            "predef": [
                "define",
                "jQuery"
            ]
        }
    }

We had to roll out a minor feature introduced in 3.0.0 because it was causing a memory leak. If you’re running a long-lived app (Windows service, web site) you’ll want this.

Only the core Autofac package was updated; the rest remained. Assembly versions didn’t change.

I’m trying to write an HtmlHelper extension that lets you dump out options that build a jQuery UI datepicker on the client. (I know there are some of these out there, but for various reasons I won’t get into… I get to make one, too.)

Something that will let me do this:

``

@Html.DatePickerFor(m => m.SomeDate);

In doing that, I’ve uncovered a lot of frustration around getting the options specified on the server over to the client and working in a consistent format.

• JSON date serialization continues to be a joke. I know there’s no date support, but it means you get to roll your own, even if several folks say they’re “standardizing” on something. jQuery.parseJSON doesn’t seem to support any sort of date from what I can tell, which means you get into custom serialization/deserialization or using some third party utility. I ended up using the Microsoft Sys.Serialization.JavaScriptSerializer because I’m using a compatible mechanism on the server and perf isn’t really a necessity given you’ve only got a couple of date pickers on a page generally, each of which only have a couple of date-oriented options.
• jQuery UI datepicker has its own date formatting mechanism. It doesn’t use the same format strings as .NET, sprintf, strftime, or anything else I can figure. Same goes for parsing. That means integration with validation (or other stuff that needs to get the date on the client) is kind of painful. It also means you either end up writing crazy date format converters or you replace the date parsing/formatting wholesale. I ended up writing tiny proxy methods that make use of the Microsoft parsing/formatting extensions because then I can also let the default MVC model binder do whatever it needs to do in a locale-aware manner without having to special-case stuff.
• jQuery UI datepicker localization is lacking. In .NET resources, you have this sort of fallback mechanism where “en-US” falls back to “en” which falls back to invariant culture. You provide the most specific culture, fallback handles the rest. Not so with the jQuery UI datepicker. You have to sort of “know” whether the specific culture is supported and/or the general culture and set it directly yourself. This, of course, means dates from the server (String.Format style) will potentially be inconsistent with dates formatted on the client side. I ended up generating all of the localized options on the server and piping them to the client rather than using the script-based localization.
• jQuery.data() hates camelCase attributes. Yeah, I know HTML attributes are all supposed to be lowercase. But try this with jQuery 1.9.0: Set up an HTML element like this: <div id="test" data-someDataHere="1">Content</div>now try and get that using jQuery.data(): var data = $("#test").data().someDataHere; It won’t work. You’ll get some sort of exception down in the bowels of things because it’s looking for an attribute that’s all lower-case-dashes like data-some-data-hererather than the actual attribute name.

Anyway, I got to find these through experience so hopefully it’ll help others save some time.

We had a safari in our living room last night.

Jenn and I are coming to find that Phoenix (now two) has a pretty great imagination. I think she fuels it with some of the stories we read and shows she watches, but the combination of all of that in her little brain is pretty crazy.

She really likes flashlights. Doesn’t really matter if it’s a head lamp, a small flashlight, or a lantern, if it’s a hand-held light source, she’s all over it. We got her a pack of flashlights for Christmas and my parents picked her up a little pink head lamp. She runs around the house looking for dark rooms to inspect, then turns the flashlight(s) on and starts looking. “Daddy, it’s dark in here,” she says. In her little kid not-quite-English it sounds more like, “Daddy, a dock a here.” But we know what she’s saying. “Spooooooky,” she says, as she walks around with the light.

Last night after dinner we were trying to figure out a game to play with her. She wasn’t really interested in the usual tea party or Brio train thing, but she was carrying around her light. At one point she told us to turn the lights off in the room, so we did. Then she handed out lights to the rest of us. Jenn got the head lamp, I got a small lantern. She continued running around to each room telling us to turn off all the lights, and we did until the whole house was dark, just us with our flashlights. I’m sure from the outside it looked like a major burglary.

Once the house was dark, I figured I’d kick things up a notch. “Hey, Phoenix, are we going to the jungle?” She totally went with it. “Jungle, Daddy! Sshhhhhhh! Tigers sleeping!” We walked around the house, inspecting all the corners of every room.

“Phoe, do you see the birds in the trees?”

“Oh, birds, Daddy! Pretty!”

Jenn decided to take it a little further. “Look out, Phoe, there’s a tiger! He’s going to get you!”

“Nooooo! No tiger eat meeeee! Ruuuuuuuuun!” She took off running, trying to escape one of our very confused house cats, who then got spooked because… well, who wouldn’t be spooked when a toddler four times your size is running rampant and screaming.

“Phoe, look, snakes on the ground,” Jenn said, getting her going even more.

“Snakes icky,” said Phoenix, shining her light on the ground. “No get me.”

I took some throw pillows and put them around on the floor. “Quick, Phoe, step on the pillows! If you stay on the path, the snakes can’t get you!” She hopped up on one of the pillows and started jumping from pillow to pillow. It occurred to me that this is her first official step on the road to the “hot lava” game we all played as kids, where you have to step on certain spots to “stay out of the hot lava.” Chalk one up for my mad parenting skillz.

We played like that for 45 minutes or so, until it was time to get her ready for bed. She was pretty sad to have to stop playing since we were having quite a bit of fun, but I’m sure that’s not our last safari.

In fact, this morning after we got her up she went straight for the flashlights. “Jungle, Daddy.” I had to laugh. “Did you have a good time playing last night? Did the tigers get you?” She nodded her head, her wild curls shaking. “Tigers no get me. Fun!”