With the WebMatrix v2 release, support was added for working with LESS. When adding a new file to a web site, we have a LESS file template as well as syntax highlighting and intellisense in the editor. Goodness all around.

Knowing nothing about LESS, I went to their website to see how to set it up and of the two options listed on the Usage page, running it client-side or server-side, I chose the former because it was first in the instructions and the latter only talked about it in the context of a Node.js site and I’m using WebPages.

So I added my LESS file to my site, added the stylesheet link to it in my markup as well as a link to the LESS js file. Then, I started run my site and saw zero CSS styling. Using the browser tools in Chrome, I could see the client side request for the “.less” file failed. I made a direct request for the file via the browser and this returned:

Bummer.

Fortunately, this error was descriptive enough to point me towards the culprit – a missing MIME map for the “.less” extension. Simply adding this to the IIS Express “applicationHost.config” file did the trick.

With this working, the other question to ask is whether or not processing the LESS file to generate CSS on the client is the best design. I haven’t thought through all of the pros/cons of this versus a server side processing approach, but my gut tells me doing this server side is probably a better choice.

So can we get the server-side design working? Well, with WebMatrix we’re in luck, because a nice extension has been written to automatically produce a corresponding CSS file whenever a change to a LESS file is saved, and here’s a write-up on How to Use LESS CSS in WebMatrix that explains this. If you’re going to be actually using LESS in your web site, this is the way to go. In this post I just wanted to point out the one roadblock you would run into if you were simply trying the client-side approach.

Hope this helps,
Mark

So how do we debug debug this? Poking around the web a bit yielded a number of recommendations. I could:

1. Enable Remote Desktop for the worker role and login to the box when it was starting up to see if I could debug the issue. This seems kind of tricky for my scenario as I’d have to catch it before it exited the “OnStart()” method.
2. I could wrap my code in the “OnStart()” method with a try/catch and log the exception to SQL Azure, Azure Table storage or write it to queue. That wouldn’t be too bad, but it does require me to update my code.
3. I could leverage the built-in Visual Studio IntelliTrace feature to record the execution history of my worker role and view this data all from the comfort of my local box.

I’m lazy so #3 sounds like a winner to me.

To configure this, you right click on your Cloud Project in Solution Explorer and choose “Publish”. Then, on the Advanced Settings tab, you can “Enable IntelliTrace” and further configure settings around how much data you want to collect. When you’re done, click “Publish” and away you go.

As Visual Studio goes through it’s publishing process an activity log is provided showing you the steps being executed. I’ve captured this below and though you can’t see the local time on my computer, I’ve been at that final step with the worker role being “busy” for a good while.

Time to look at that IntelliTrace data!

Using the Server Explorer window in Visual Studio, I can now view the IntelliTrace logs by expanding the Windows Azure Compute section and locating my worker role.

This triggers a download of the data to your local machine and once the download completes, Visual Studio pops open the IntelliTrace Summary in a new window. Now I can see the list of exceptions that were generated and where they occurred.

The screenshot below shows the dummy exception I intentionally added to cause my worker role to fail to start.

At this point, I can take things one step further by clicking the “Start Debugging” data to see the exact state of my worker role when the exception was triggered, fix up my bug and redeploy.

Hope this helps,

Mark

In the portal, click on the Storage section and then a storage account. You’ll see a new “Containers” menu option (circled in red in my screenshot).

Clicking on the link will give you a list of all containers for the storage account and at the bottom of the screen a button to delete a container and all associated data.

You can then drill down into an individual container, look at the individual blobs in the container and delete them if desired.

Hopefully we’ll one day have the ability to also add containers and blobs, but for now, I’ll take what I can get.

Mark

The URL is http://cloudydeveloper.blob.core.windows.net/images/2012/09/AzureHomePage.png.

If you look at the domain in the URL, you’ll notice it’s not www.cloudydeveloper.com. The image is not hosted on the same box running this WordPress site. Instead, it’s hosted in my Azure storage account thanks to the new Windows Azure Storage for WordPress plugin. This plugin allows images and videos to be stored in Azure “blob” storage which is super cheap. While I’m nowhere near hitting the storage limit for this Azure web site, I like the idea of getting larger media assets in a more suitable location and at $0.12 a GB a month, I’m not concerned about breaking the bank in the near future.

Here’s how I set this up:

1. Install the plugin.

   From the WordPress admin console, I just searched for the plugin “Windows Azure Storage for WordPress” and installed it.

   
   

2. Configure the plugin.

   In the settings tab of the WordPress admin console, click on “Windows Azure”. You’ll first need to create an Azure storage account to hold your media assets and have the name of the storage account and access key handy. In the screenshot below, I’ve already set this up and created a “container”, which is like a folder for storing blobs, named “images”, but if I hadn’t already done this, you’d see the ability to create a new container from this screen.

   
   

3. Enable XML-RPC publishing in WordPress.

   Again, in the WordPress admin console, go to Settings –> Writing and enable this.

   

And that’s it.

I use Windows Live Writer to create my blog posts and I just include images just like I did before and on publish, the plugin uploads the images to my Azure storage account and generates the correct URL. No extra work needed on my part. Awesome.

Mark

Here’s the updated Azure portal UI with the new “Web Site Mode”:

I’m currently configured to use the “Reserved” mode but you can see the new “Shared” mode in the middle and details about the mode in the pop-out.

I won’t walk through the details of setting this up as the necessary steps are well outlined in the following posts:

• Configuring the new “Shared” hosting option
• Configuring a custom domain for a Windows Azure web site

Hope this helps,

Mark

Next, I committed the file to Git and then a “git push” to send the files to Azure. The deployment was built successfully on Azure and my site was re-deployed. Easy peasy.

I hit the site in my browser, typed in the link to the Word document and was sadly greeted by a 404.

Being logical, I assumed the 404 was correct and the file didn’t exist so I FTP’d to my account to look at what Azure had on disk. Sure enough, the file wasn’t there.

Huh?

I double checked Git to ensure the file had been committed properly, pushed to Azure once more and received the same result. No Word doc in Azure.

This type of problem gives me pause. I had to take a step back and think about what was actually happening with each step of the process.

• File in local site – check.
• File committed to Git – check.
• Git push successful – check.
• Project built successfully on Azure – check.

Looking at these steps, in only the last one that I didn’t have full control over so I started my investigation there and it dawned on me – not all content in a site is actually “output” during build.

This led me to look a the properties for the Word doc and lo and behold, I had:

“Build Action” was set to “None” so my Word document was never “output” when the project was built. You can read the meaning of each “Build Action” value on this MSDN File Properties page. The relevant info is:

• None – The file is not included in the project output group and is not compiled in the build process. An example is a text file that contains documentation, such as a Readme file.
• Content - The file is not compiled, but is included in the Content output group. For example, this setting is the default value for an .htm or other kind of Web file.

Simply changing it from “None” to “Content” did the trick. I checked in the change to Git, published one last time and there was my Word document.

I went through this process using Visual Studio 2010. Fortunately, in Visual Studio 20120, we’ve changed the default “Build Action” to “Content” for file types not recognized as being web specific. Hat tip to teammate Jimmy Lewis for pointing this out.

Quick side note – if Git publishing to Azure is your thing, be sure to check out recent improvements with publishing hooks for CodePlex and GitHub. As usual, Scott Guthrie has a nice blog post describing these recent improvements.

Hope this help someone avoid a bit of headache in the future.

Mark

ko.obsevable(accountName);

Notice that I misspelled “observable”. I didn’t realize my error until I ran the site. Using the developer tools in the browser, I could see my typo. I started to correct this and then it struck me – why didn’t intellisense save me from this mistake? Simply put, I didn’t have the right headers at the top of my file to invoke it.

By simply adding:

/// <reference path=”../Scripts/knockout-2.1.0.js” />

Typing “ko.ob“, now returns:

Quick gotcha – after adding the reference to the script, I had to close and re-open the file in WebMatrix.

I’ve seen some folks mention on StackOverflow that instead of the attribute name “path”, they had to use “file”, but both of these seem to work for me.

Looking at your scripts folder, you might notice some files which include “vsdoc” in their name. These are special files which contain additional intellisense information. We have one for jQuery and we get much richer intellisense for that script.

For example, after typing “$(“:

Notice that we get a lot of additional info around the API. If you crack open the “jquery-1.7.2-vsdoc.js” file, you’ll see all of this additional content listed.

So in short, it’s trivial to get some basic intellisense functionality for JavaScript in WebMatrix if you add the right references to the top of your files. If for some reason this doesn’t work for you, double check that the path reference is correct. That’s another common mistake I’ve made.

Hope this helps,

Mark

The technique is to use Domain Masking. I’ve seen it also called URL Frames, URL masking and URL cloaking. It depends on your domain registrar. Regardless, the trick is for the browser to use a URL redirect in conjunction with a frame to load a web site while preserving the custom domain name in the address bar. This isn’t as clean as using a CNAME record which avoids the redirect and doesn’t use a frame, but it’s a simple alternative that might meet your needs.

You can see this in action if you visit bushschooladventure.com. A request to the web site causes a browser redirect to bushschooladventure.azurewebsites.net which is where the site is actually hosted.

Here’s the network trace for the request in Fiddler:

Notice that request #2 results in an HTTP 302. That’s the browser redirect from “bushschooladventure.com” to “bushschooladventure.azurewebsites.net”. Looking at the URL address in the browser though, it still says “bushschooladventure.com” which is perfect. If I had used a plain URL redirect, the address bar would have shown “bushschooladventure.azurewebsites.net” which is undesirable.

Looking at the page source, we can see a <frameset> being used:

<frameset>

    <frame src=”http://bushschooladventure.azurewebsites.net“></frame>

</frameset>

To configure this with my domain registrar, Namecheap, I set the following hostname records for a “URL Frame”. GoDaddy calls it domain masking.

You can’t see the full URL in the text boxes there, but I assure you that it points to “bushschooladventure.azurewebsites.net”.

And that’s it! A custom domain name for my Windows Azure Web Site without running the site on a reserved instance machine.

Hope this helps,
Mark

As I was fixing up my references, I decided to do more research on CDNs, and I learned some interesting points that I wanted to share. First though, let me cover the basics.

CDN Basics

A CDN usually hosts a common file used by many applications. In the web world, scripts like jQuery are a great example of this. There’s no need for an application to pull this script from the local web server. Instead, they can point at Microsoft’s CDN and the browser will download the script from there. The Microsoft CDN hosts a number of resources beyond the base jQuery script. You can pick up jQuery UI, jQuery validation, jQuery Mobile and many others.

Here’s an example comparing a local versus a CDN script reference (please read the final point in this post about the “http” gotcha):

One obvious advantages here is that I’m not using network bandwidth for my site to send down the script. It’s also likely that the CDN is able to serve up the script faster. After doing some research though, I learned a few less obvious advantages, downsides and tips that I thought were worth sharing.

Less Obvious CDN Advantages

Cross-site caching

Imagine you’re visiting a number of different web sites and they all use the same version of jQuery, but they all host the jQuery script locally. Each time your browser requests a page from one of the sites, it downloads a copy of jQuery. If instead each of these sites pointed to the same CDN for the jQuery script, the browser would only download it once for the first site visited. When you visited the second site, the browser would see the need to download jQuery from the CDN, but we’d get a browser cache-hit for the script and nothing would be downloaded again.

Below is some HTTP traffic captured with Fiddler for requests made to two different web sites. Both sites have a reference to the jQuery script stored on Microsoft’s CDN. Notice that the first request for this script (request #10) resulted in a download of the script and an HTTP 200 response. The second request for the script (request #70) was to a different web site but didn’t require re-downloading the script. The browser made a request for it and the server (the CDN) responded with an HTTP 304 indicating the script contents have not been modified.

This is the cross-site caching effect. As more web sites reference a CDN for common resources, the chance of the client’s browser getting a cache hit when requesting such scripts goes up.

Increased browser request parallelism

Internet Explorer has settings which restrict the number of outstanding requests to a single web server and I’m sure the other browsers have similar restrictions. This Microsoft KB article talks about how to tweak this setting for IE.

Having resources pulled from a CDN means the browser is making requests to a different server than the one serving up the original web page so these requests don’t count against this “max connections per server” browser setting.
 

Potential Downsides to CDNs

I knew there had to be a few downsides to using CDNs. Here are a couple of them that I found interesting.

1. What if the browser can’t reach the CDN? Like any other server, it’s possible that it could go down although I’d argue that it’s more likely your web server will go down than one of the major CDN’s.
2. There might be some additional engineering cost to tweak your resource references on deployment to convert from locally referencing files to referencing the CDN. You could avoid this by also targeting a CDN when doing development, but that will likely be slower than having the script loaded from your local machine.
3. The version of the resource you’re referencing is dropped from the CDN. This is always possible although I’m betting a good CDN would keep a long history of past versions of files. Still, you probably want to pay some attention to this so that you’re not caught off guard.
   
4. When working with an Intranet based site, hitting a CDN might be slower than the local machine since it’s likely to be physically closer to the machine making the web request.

The HTTP/S Reference Gotcha

This issue was completely new to me. In most of the examples I’ve seen where folks show updating their resource references to CDNs (including the one at the beginning of this post), they precede the reference with “http”.

There’s a problem with this. If the resource is referenced in a page that’s downloaded securely via “https”, the browser will generate a warning and will not download the resource from the CDN because it’s not specified using “https” as well.

Here’s what happens when such a page is requested in Chrome:

Notice the warning at the top of the page and the recommended action. If the user decides to not load the content, your site could break if it depends on the resource that doesn’t get loaded.

A quick fix might be to always download CDN resources via “https”, but that’s overkill as you might have other pages in your site that use the same resource yet those pages are meant to be requested with a standard “http” connection. In such cases, we wouldn’t want to incur the browser overhead of making an “https” connection to the CDN when it’s not needed.

Fortunately, there’s a simple trick to have the CDN resource downloaded via “http” or “https” depending on how the referencing page was requested. Just trim off the leading “http:” or “https:”.

When processing this script reference, the browser will automatically prepend it with either “http” or “https” depending on the method used to request the referencing page.

Hope this helps.

I wasn’t able to quickly find this information out with a web search, so here it is once and for all:

(localdb)\v11.0

Happy developing