Tuesday, March 25, 2014

Browser Link and Slow Page Loads while Debugging with VS 2013

I recently started noticing sluggishness in IE 11 when debugging a MVC 4.5 app with VS2013. Specifically, after a page would seemingly load, it wouldn't respond to my mouse movement until what seemed like a full second or two later. It was concerning. I had been making a lot of changes, especially around the inclusion of images, and I figured I'd done something less than ideal that was causing the page load time to increase. So I hit F12 and start capturing network traffic:

Besides a couple issues that I need to look at, one thing appeared odd to me: the second-to-last line with a URL of "/__browserLink/..."

I wasn't sure what it was, but it appeared to be the issue. I then find out that this is a new and pretty useful tool for testing with multiple browsers. And there is an easy way to disable it when not needed, which resolves the slowness issue.

IE seemed to suffer a little more from the Browser Link delay than did Chrome.

Thursday, March 6, 2014

Using Shared Scripts in Azure Mobile Services

Windows Azure is outstanding. If you haven't checked it out, do so: WindowsAzure.com/. They provide a free trial if you want to experiment. You also get free compute time if you have an MSDN account.

There are, of course, tasks in Azure that require know-how. One of those tasks that took me a good deal of time to get right is using shared scripts in Azure Mobile Services.

Background on Mobile Services

With mobile services, you're given an easy way to intercept and modify the calls from your apps before they perform database CRUD actions. You do this using Node.js scripts. The common examples I've seen shows how to compare the UserId of the user to that of individual records being affected by the request. For instance, in the Read script you might do this:

        query.where({ UserId: user.userId });

This appends an additional where clause to your query so that it is filtered to return only records where the UserId field matches the requesting user's Id. (This assumes you've specified that the permissions for the particular table script is set to "Only Authenticated Users.")

But sometimes you want to perform other actions, such as looking up data from another table, logging activity, updating data, etc., prior to submitting the actual request passed by your app. If you need to perform these common tasks across a number of service calls, you have the option of writing that code once and sharing it across all service methods. But this is where I struggled...how to get it set up and working correctly.

Creating and Using Shared Scripts

By default, the Azure management tool provides an easy way to manage your table scripts. But the tool doesn't provide visibility (yet) to shared scripts...that is, scripts not tied to one particular table action (insert, update, delete, read). To do this, you have two options: (1) set up a Git repository and configure that in your mobile service or (2) use the Azure command-line tool to upload/manage shared scripts. I'm not using Git, so I opted for the command-line tool.

Task #1 - installing the command-line tool

The first problem I ran into was that, after installing the tool, I was confused on which tool to use. I had a few show up in my search from the Win 8 start screen:

Later, I found this useful tip from Chris Avis in a TechNet blog, which enabled me to find a helpful command line tool that for some reason isn't visible after installing from the above link:
"Interesting Tidbit – PowerShell ISE gets installed as a part of this process, but you won’t find it by searching on the Start screen of a Windows 8 machine. But it is there! You just have to dig for it.  It is actually located in the Control Panel –> Administrative Tools area"
This tool includes a nice utility to search through various commands.

Task #2 - managing shared scripts from the command line

From the command line, you can view and manage all of your scripts (table, shared and custom). Here's a helpful list of script commands. Before you do that, however, you need to link your Azure account to the command-line tool:

azure account download

That will open a browser prompting you to sign in, upon which it will download the publish file so that you can reference that with your next command:

azure account import <path-to-settings-file>

See the documentation which explains this process in more detail. Once you have your account set up, you can begin uploading your shared scripts. For example:

azure mobile script upload mytestservice shared/myscript.js -f c:\users\tim\documents\myscript.js

Note that I had trouble with the above command without specifying the script file location using the -f option.

Task #3 - using the shared script in your table scripts

Finally, here's an example of consuming a shared script from within a table script:
function read(query, user, request) {
    // retrieve the shared module for common code
    var shared = require('../shared/myscript'); //note the absence of the .js extension
    // Test for compliant app version
    if (!shared.isAppVersionValid(request.parameters.AppVersionNumber))
        request.respond(statusCodes.BAD_REQUEST, 'The app version is not valid');
Carlos Figueira (MSFT) has produced a number of helpful posts on working with Mobile Service scripts. The Azure documentation also contains good information. I found the following pages to be the most helpful in getting a handle on mobile service scripts and shared scripts: