Copyright © Microsoft Corporation. All rights reserved.
    The code provided in this post is licensed under the Microsoft Public License (Ms-PL).
Aug
16
2013

Start Developing for Windows (8.1) Store Apps using HTML5

jumpstartstudioWhen Windows 8 was first introduced, a huge opportunity opened up for web developers.  How so?  Anyone with HTML, CSS, and JavaScript skills could now apply such skills to developing apps, not just sites.  This is due to Microsoft supporting the development of WinRT apps with either C++, .NET, and/or JavaScript.  How different is it from writing a web site vs. an app?  If you are a web developer and you want to find out, be sure to look at the DevRadio episodes on developing for Windows 8 in half the time (4 minute videos) or the comprehensive “jump start” training series on HTML5 for Windows 8.  Moving onward, it will be assumed you already have a degree of experience with developing apps for Windows 8 using HTML5, and you are interested in what’s new or changed.

With Windows 8.1, consumers will enjoy a richer, more interactive experience. Correspondingly, the  APIs have been updated, providing developers either new or easier ways of doing things. A listing of the API deltas can be found at the Windows Dev Center for Windows Store apps.  Our focus right now is not to do a tedious overview of everything new.  Rather, we will look at what you need to do to get ramped up with some highlighted features as quick as possible.

Developer Requirements

To get started, you will need to install Windows 8.1 (preview is available for download) and Visual Studio 2013 (preview is available for download).  You should also highly consider registering at the App Builder site for relevant resources.

Visual Studio 2013 Updates

Creating a new project with Visual Studio 2013 is much like it was with Visual Studio 2012.  Consider the following screen capture of the “New Project” dialogue box:

vs13_new_project

First point of interest is a new template type named “Hub App” which allows for a hierarchical system of navigation. The template uses a new Hub control, and you can learn more about it if you download the Hub control sample. Regardless of which template type used though, let’s examine some core changes. 

WinJS 2.0

The source page of HTML files now target Windows 8.1, as indicated by the references to WinJS 2.0 as seen here:

<!-- WinJS references -->
<link href="//Microsoft.WinJS.2.0.Preview/css/ui-light.css" 
     rel="stylesheet" /> <script src="//Microsoft.WinJS.2.0.Preview/js/base.js"></script> <script src="//Microsoft.WinJS.2.0.Preview/js/ui.js"></script>

You will also see this visually in the solution explorer view.  When expanded, it is easy to see the resources being requested as seen here:

vs13_ref

Note that when you open a project created for Windows 8, Visual Studio 2013 will prompt you to determine if the project should now target Windows 8.1

Editor Enhancements

A pleasant enhancement to the JavaScript editor is the automatic completion of code blocks when typing the left side of the block.  For example, when typing a left brace { , the editor will pair it with a right brace } and auto-format along the way.  Other pairings include parenthesis, brackets, and quotation marks (single or double).

The editor will also highlight identifiers when selected.  For example, if a variable is declared with the name isAwesome, notice how the editor will highlight where else it is used:

vs13_id

Tiles

One more quick change to be aware of is found in the package.appxmanifest file.  When opening in Visual Studio 2013, you will find the Application UI tab where you can configure the images used for your apps tiles.  However, notice the new options as seen here:

vs13_logos

These new options introduce both a larger and smaller tile.  You should support these new tile sizes so that users of Windows 8.1 can easily organize their Start screen.  The example below shows the 70x70 in upper left, 150x150 in upper middle, 310x150 in the lower left, and the 310x310 on the right:

What Next?

So much could be next.  To some degree that will depend on the type of app you are developing.  The information covered so far is to enable a quick start to the development process.  By setting up the required environment and understanding a few of the changes in Visual Studio 2013, you can start coding as usual.  Look for deeper looks at specific features in the near future!

    Copyright © Microsoft Corporation. All rights reserved.
    The code provided in this post is licensed under the Microsoft Public License (Ms-PL).
Feb
15
2013

HTML5 Apps 70-480

Elevate! Electrify!

image

Jeremy Foster and I had no idea what kind of response resulted from presenting our free training course to prepare for the 70-480 exam.  For example, who knew that our shirts (purchased from the Microsoft Store the day prior) would become so popular, people contacting both of us wondering where they could buy one?

That said, the real story is in the successful outcomes of those who watched the videos and then subsequently passed the exam.  Even more impressive to me personally is that some already have apps submitted to the Windows Store!  (Do you have an app in the store? If not, consider 30,000 reasons why you should submit your app now!)

A Jump Start to the Jump Start

I want to give a Matthew Hughes in the United Kingdom recognition for his outstanding coverage of this course.  He took meticulous, detailed notes on every topic.  I have organized his blog posts below:

Part 0    Getting Started

Part 1    Semantic Markup, Forms, Media and SVG

Part 2    Cascading Style Sheets (CSS)

Part 3    Advanced Layouts and Animations

Part 4    JavaScript Core Capabilities

Part 5    Manipulating the DOM

Part 6    Advanced Topics

    Copyright © Microsoft Corporation. All rights reserved.
    The code provided in this post is licensed under the Microsoft Public License (Ms-PL).
Dec
4
2012

Microsoft DevRadio: Promises

To play video, hover above and press play button.

Abstract: win8genapp30
Michael Palermo and Jeremy Foster discuss the role of promises and demonstrate via codeSHOW.

Watch previous episodes here...
    Copyright © Microsoft Corporation. All rights reserved.
    The code provided in this post is licensed under the Microsoft Public License (Ms-PL).
Nov
19
2012

Microsoft DevRadio: Adding an App Bar

To play video, hover above and press play button.

Abstract: win8genapp30
In this episode, Michael Palermo shows how easy it is to add an application bar to your app!

Next Steps:
Step #1 – Download Windows 8 and Windows 8 SDK
Step #2 – Download Visual Studio Express for Windows 8
Step #3 – Start building your own Apps for Windows 8

Subscribe to our podcast via iTunes, Zune, or RSS

If you're interested in learning more about the products or solutions discussed in this episode, click on any of the below links for free, in-depth information:

Websites:

Developing for Windows 8 in 1/2 the time!

Watch previous episodes here...
    Copyright © Microsoft Corporation. All rights reserved.
    The code provided in this post is licensed under the Microsoft Public License (Ms-PL).
Oct
22
2012

Microsoft DevRadio: Using Event Handlers

To play video, hover above and press play button.

Abstract: win8genapp30
In today's episode, Michael Palermo shows how easy it is to attach event handlers in JavaScript. Watch this short demo to see the various techniques to do it!

Next Steps:
Step #1 – Download Windows 8 and Windows 8 SDK
Step #2 – Download Visual Studio Express for Windows 8
Step #3 – Start building your own Apps for Windows 8

Subscribe to our podcast via iTunes, Zune, or RSS

If you're interested in learning more about the products or solutions discussed in this episode, click on any of the below links for free, in-depth information:

Websites:

Developing for Windows 8 in 1/2 the time!

    Copyright © Microsoft Corporation. All rights reserved.
    The code provided in this post is licensed under the Microsoft Public License (Ms-PL).
Oct
8
2012

Microsoft DevRadio: Developing for Device Features

To play video, hover above and press play button.

Abstract: win8genapp30
Ever wonder how you can develop for device features you really like even though your personal device doesn’t support it? Well in this episode, Michael Palermo shows you the power of the Simulator in Visual Studio and how you can test features for various devices.

Next Steps:
Step #1 – Download Windows 8 and Windows 8 SDK
Step #2 – Download Visual Studio Express for Windows 8
Step #3 – Start building your own Apps for Windows 8

Subscribe to our podcast via iTunes, Zune, or RSS

If you're interested in learning more about the products or solutions discussed in this episode, click on any of the below links for free, in-depth information:

Websites:

Developing for Windows 8 in 1/2 the time!

    Copyright © Microsoft Corporation. All rights reserved.
    The code provided in this post is licensed under the Microsoft Public License (Ms-PL).
Oct
2
2012

JavaScript for Windows Store Apps: View States

Creating an application for the Windows Store requires forethought to a number of considerations – one of which is how will you want your app to appear when seen in different view states.

When your application is running full screen in Windows 8, it will be in either landscape or portrait orientation.  When the orientation is landscape mode, two additional views are possible: snapped or fill.  A snapped view is docked either on the right or left side of the screen, with a width of 320px.  The fill view is the larger remaining portion of the screen when another app is in snapped view. 

Note Snapped and fill options are only available when the screen resolution is a minimum of 1366 x 768 and supporting wide screen (16:9) aspect ratio.

When developing apps using JavaScript, you have two main ways to manage the view states in your apps:  Programmatically via JavaScript, or declaratively with CSS3 Media Queries.  It is recommended that you use media queries to manage view state changes.  However, there are times when you will need to respond to a view state change in code, and that is going to be our focus in this post.

What is Your Current View?

The Windows.UI.ViewManagement namespace provides some classes and enumerations for managing an applications view.  The ApplicationView class can be used to determine the applications current view state by calling the value property.  The return type of value is numeric, and maps to the ApplicationViewState enumeration.  Armed with both, the following code shows a helper method for returning a string with the current view state name:

var appView = Windows.UI.ViewManagement.ApplicationView;
var viewStates = Windows.UI.ViewManagement.ApplicationViewState;

function getViewStateName(viewState) {
    viewState = viewState || appView.value;
    var vs;
    switch (viewState) {
        case viewStates.fullScreenLandscape: // 0
            vs = "FullScreenLandscape";
            break;
        case viewStates.filled:              // 1
            vs = "Filled";
            break;
        case viewStates.snapped:             // 2
            vs = "Snapped";
            break;
        case viewStates.fullScreenPortrait:  // 3
            vs = "FullScreenPortrait";
            break;
        default:
            vs = "Unknown";
            break;
    }
    return vs;
}

The above code is useful for determining what the current view state is.  What about being notified when a view state change occurs?  One way to accomplish this is by responding to the resizing of the window as seen here:

// manage view state in anonymous handler
window.addEventListener("resize", function(){ }); 

The above line of code would allow you to write code in the anonymous function to query the applications view state and respond accordingly.

If you happen to be using Page Controls you are also likely using the PageControlNavigator, which is a class defined in a navigator.js file included in Visual Studio projects that support single-page navigation model.  Let’s look under the hood of PageControlNavigator, particularly when it responds to the application resizing:

_resized: function (args) {
    // if a page control exists and has updateLayout defined
    if (this.pageControl && this.pageControl.updateLayout) {
        this.pageControl.updateLayout.call(
            this.pageControl,  // instance of pageControl
            this.pageElement,  // element containing page 
            appView.value,     // current view state
            this.lastViewstate // previous view state
        );
    }
    // capture view state
    this.lastViewstate = appView.value;
},

The above snippet of code shows what the PageControlNavigator does when it responds to resizing.  The code checks to see if the current page control has defined an updateLayout function, and if it has, it calls it with parameters useful for interrogating.  Now let’s look at an example of an updateLayout function inside a page control:

updateLayout: function (element, viewState, lastViewState) {
    /// <param name="element" domElement="true" />

    // TODO: Respond to changes in viewState.
    pageTitle.innerText = getViewStateName(viewState);
}

In the example above, an element with the ID of “pageTitle” sets it’s text to equal the response of the helper method shown previously – which returns a string with the current view state name.

Responding to a Different View

Now that we have established where to write code when the view changes, it is now time to focus on what you might do in that response.  Suppose you have a ListView control on the page that displays items in full screen mode like so:

SNAGHTML1e5e652d

Now when going to snapped view, it looks like this:

image

Notice in snapped view the scroll bar is still moving horizontally.  What if we want the list to scroll vertically when in snapped view?  This is where a few lines of code can make the difference to improve the user experience.

The ListView has a layout property that allows you to change from a horizontal grid to a vertical list.  When a view state change occurs, the following code conditionally switches the layout:

// viewStates is Windows.UI.ViewManagement.ApplicationViewState;
if (viewState == viewStates.snapped) {
    // vertical scrolling list of data
    list.layout = new WinJS.UI.ListLayout();
} else {
    // horizontal scrolling grid of data
    list.layout = new WinJS.UI.GridLayout();
}

The code above (written inside the updateLayout function) changes a ListView control with an ID of “list” to switch to a different layout if the view state is snapped, otherwise it reverts to the original grid layout.  Doing this along with some tweaks to CSS via media queries (such as adjusting margins) results in the improved UI when in snapped view:

image

The content can now be scrolled vertically!

Embrace a Different Point of View

No doubt you will enjoy being a user of applications running on Windows 8.  One of the features that is sure to be used by multi-tasking enthusiasts is running apps in snapped & filled modes.  Make sure you when you develop apps for the Windows Store, you create a compelling UI for each view.  Also make sure to take advantage of all the resources available at Generation App!

    Copyright © Microsoft Corporation. All rights reserved.
    The code provided in this post is licensed under the Microsoft Public License (Ms-PL).
Sep
27
2012

JavaScript for Windows Store Apps: Error Handling

Are you confident you are writing your JavaScript code error free?  Do you wonder if traditional JavaScript error handling techniques still apply when developing for Windows Store apps?  Does the Windows Library for JavaScript provide additional support for error handling?  Do you deal with errors differently when writing asynchronous code?  This entire post is dedicated to addressing these questions!

To Err is Human

Let’s be clear – if you were perfect and could write code that never fails, you would not need to read any further. For the rest of us (which is all of us), we must acknowledge that errors very often creep into code.  Furthermore when developing with a language that is not strongly-typed such as JavaScript, there is potential for even more errors.  Why? Consider the following code:

var x = 4;

// somewhere else in code...
x = "four";

The above code is valid.  It showcases the dynamic nature of the language. However, it also illustrates the potential confusion as to what the variable x is. Any misuse of x based on assumptions could lead to buggy behaviors.  One way to minimize these kind of issues is to be consistent with variable assignments with regard to inferred type. In other words, if a variable is assigned to a string, keep it a string.

Syntax errors are typically reported through Visual Studio when running the application in debug mode.  However, the error message may not clearly state what is needed for correction.  For example, observe the following syntax error:

varr x = 4;

Isolated from all other lines of code, it is easy to see that the keyword var was misspelled. Yet the IDE reports the error at runtime this way:

javascript critical error

An entry level scripter could debate that there is a ‘;’ at the end of the line, and rationalize the error message itself is erroneous.  The moral of the story here is to examine the complete line of code and surrounding context for discrepancies when the reported error message is not clear.

For web developers who are bringing their JavaScript skills over to Windows Store app development, the use of try…catch…finally statements are fully supported and should be used when attempting to execute any line of code that is conditional to a successful outcome – such as accessing external resources.

Mistrust is a Virtue

I find it a little humorous that the uninitialized use of WinJS.log (a method for logging error information among other things) will cause an error to be thrown at runtime.  The log method can be initialized with WinJS.Utilities.startLog (for logging to the JavaScript console) or assigned to a custom method with logging behaviors defined by the developer.  A straight call to the log method without initializing will cause following:

JavaScript runtime error: Object doesn't support property or method 'log'

Of course, when the log method is initialized - no errors are reported.  However, consider a scenario where settings in the application determine whether the log method will be initialized or not.  In that case, what is a safe way to call the log method?  Some might create a global variable that could be used in an if statement to see if logging is enabled before every call.  That will work, but there is another way.  Consider the following code:

WinJS.log("Risky", "demo", "info");
WinJS.log && WinJS.log("Safer", "demo", "info");

The second line of code is “safer” because it starts with a check to see if the log exists.  The term “safer” is used instead of “safe” because by saying log “exists” what that really equates to is that it is not one of the following: null, undefined, an empty string, or a numeric value of zero.  Even so, it is still safer to use the logical && operator (no if statements needed) because it will exit the statement immediately when a false value is returned.

There is another technique using the || operator which can help reduce errors by producing a default value if one is not provided.  In the following code, the name parameter is given a value if none were already assigned:

function echoName(name) {
    name = name || "John Doe";
    return name.toUpperCase();
}

The above code will produce the following output:

echoName();             // JOHN DOE
echoName("M Palermo");  // M PALERMO

So far so good, but what if the following call is made:

echoName(4);

Passing in a non-string value causes the following error:

JavaScript runtime error: Object doesn't support property or method 'toUpperCase'

To prevent unwanted errors like this, there needs to be a guarantee that the method is safe to call. One way to do so is by using an approach mentioned previously - as seen here:

if (name && name.toUpperCase) {
    // safely call name.toUpperCase();
}

At other times it may be more preferable to simply confirm what type it is.  A common way to accomplish this is to use the typeof operator which returns a string declaring what the underlying type is as seen here:

var x;
(typeof x === 'undefined') // true

x = 4;
(typeof x === 'number')    // true

While typeof performs as expected in most cases, there are other times it may resolve types different than we could, as seen here:

(typeof 'abc' === 'string')             // true
(typeof new String("abc") === 'string') // false – type is object

In order to determine the actual type value, consider implementing a helper function like the one demonstrated here:

function isTypeOf(o,t) {
    if (t && t.charAt && t.charAt(0)) {
        return (Object.prototype.toString.call(o) === "[object " + t + "]");
    } else {
        throw new WinJS.ErrorFromName("args", 
            "'t' required and must be a string.");
    }
}


isTypeOf("abc", "String");             // true
isTypeOf(new String("abc"), "String"); // true
isTypeOf(4);                           // error thrown

The isTypeOf function first checks to see if the t parameter has a value, that the value has a charAt method, and that a call to charAt(0) will not return an empty string. If all conditions are true, the function returns a value based on the comparison of t and the type exposed from Object.prototype.toString.call.  Note that if the t parameter is not provided or not a string, an error is thrown using the WinJS.ErrorFromName factory method which is an easy way to create an error object based on name (error type or category) and message.

So why throw an error?  Doesn’t that defeat the purpose of preventing problems in the first place?  In the above example, the error is thrown from inside a helper function. Because this function could end up in a reusable library, it is a methodology for communicating it is being misused to application level code.  With that understanding, you will likely spend far more time handling errors in the application level code vs. throwing them.

The main message up to this point is to take preemptive strikes in your code to minimize errors as much as possible.  Now what about the errors that went unhandled?

Leave Nothing Unhandled

For all the unknown errors that could happen in your application, there is a simple way to catch them all in one place. The WinJS.Application object has an onerror event that traps all unhandled errors in one place.  Because error could happen at any time, this should be hooked to an event handler as soon as possible in the application lifetime.  Most of the JavaScript project templates for the Windows Store contain a default.js file where application initializing occurs.  Near the top of that file, you can add an event listener for unhandled application errors like seen here:

(function () {
    "use strict";
    
    WinJS.Binding.optimizeBindingReferences = true;

    var app = WinJS.Application;
    var activation = Windows.ApplicationModel.Activation;
    var nav = WinJS.Navigation;

    app.addEventListener("error", function (err) {
        var md = Windows.UI.Popups.MessageDialog;
        var msg = new md(err.detail.message, "Ooops!");
        msg.showAsync();
        // return true; // only if error is handled
    });

    [remaining code...]

})();

If an unhandled error happens anywhere in the application, the above listener function gets called.  A message is displayed to the user indicating the details of what has occurred, and then the app stops. The app terminates because the error is still considered unhandled. Returning true from the error handler communicates to the system that the error has been handled and is ok to continue.

Unhandled errors can also be caught at the page level while the page is processing.  This is especially easy to do when using WinJS.UI.Pages.  The following code is an example of how to add an error event listener for the PageControl instance within the define method:

WinJS.UI.Pages.define("/pages/errors/errors.html", {
 
    error: function (err) {
        WinJS.log && WinJS.log(err.message, "demo", "error");
    },

    [remaining code...]

});

It is worth repeating that this event only fires if an unhandled error occurs during the initial processing of the page. Therefore, unhandled errors that occur in after the processing of a page (in a click event for example) will be directed up to the application level for inspection.

When Promises are Broken

Promises allow for asynchronous code, and because this introduces it’s own level of complexity, it is important to know how to handle errors when using them. In order to appreciate the different options available, consider the following example of a custom promise:

function doAsync(msg, limit) {
    return new WinJS.Promise(
        // c complete, e error, p progress
        function (c, e, p) {
        msg = msg || "no-msg";
        limit = limit || 3;
        var seconds = 0; 
        var iId = window.setInterval(function () {
            try {
                seconds++;
                if (msg === "fail") {
                    throw new WinJS.ErrorFromName(
                        "promise", "Muhahaha!");
                }
                p && p(msg + ": " + seconds.toString());
                if (seconds > limit) {
                    window.clearInterval(iId);
                    c && c(msg);
                }
            } catch (ex) {
                window.clearInterval(iId);
                e && e(ex);
            }

        }, 1000); // repeat every second, stop at limit
    });
}

The doAsync function defined above is a custom promise.  When called, it allows a message (provided into the function via the msg parameter)  to be used after a number of seconds (determined by the limit parameter) passes by.  When the time limit is reached, the “complete” function(represented by c parameter) is called.  A “progress” function (represented by p parameter) is called every second, allowing the application to potentially update the UI.  And if any errors occur, the catch block passes the error into an “error” function (represented by e parameter).  If the value of msg equals “fail”, an error is thrown.

The following code demonstrates all the helper methods that will be used when calling the doAsync function:

function doComplete(msg) {
    WinJS.log && WinJS.log(msg + ": complete", "demo", "info");
}

function doProgress(msg) {
    WinJS.log && WinJS.log(msg, "demo", "info");
}

function doError(err) {
    var msg = "undefined error";
    if (err) {
        msg = err.detail;
        if (!(msg && msg.message))
            msg = err.message || "err type unknown";
    }
    WinJS.log && WinJS.log(msg, "demo", "error");
}

Each function calls on WinJS.log  to display data. Now here is the code that brings them all together:

doAsync("promise", 4) // doError not called
    .then(doComplete, doError, doProgress);
    // final call was to doComplete function

doAsync("fail", 4) // doComplete not called
    .then(doComplete, doError, doProgress);
    // final call was to doError function

In each call to doAsync above, a message is passed in, and the duration of the asynchronous call will be limited to 4 seconds.  Each second that ticks by will cause the doProgress function to be called. If all goes well when the 4 seconds are up, the doComplete function is called.  However, if the promise encounters an error, the doError function is called instead.

Promises can be chained together to allow one asynchronous call to invoke the next when completed.  When chaining promises together, put the error handler only in the final link of the chain – the done method.  Here is an example of chaining promises using the doAsync function:

doAsync("chain(1)", 4)
    .then(function (msg) {
        doComplete(msg);
        return doAsync("fail", 4);
    }, null, doProgress)// null passed in for error
    .then(function (msg) {
        doComplete(msg);
        return doAsync("chain(2)");
    }, null, doProgress)// null passed in for error
    .done(null, doError);
    // doError only needed in done method

In the promise chain above, when “chain(1)” is complete it calls on “fail”.  Since “fail” will cause an error to be thrown, “chain(2)” is never called, and processing is directed to the doError function passed into the done method of the chain. 

Promises can also be joined together too.  This allows multiple asynchronous calls simultaneously, but allowing a method to be called when all the joined promises complete.  When handling errors in this scenario, do the following:

var promises = [];
var i = 0;
// each promise has an error handler
promises[i++] = doAsync("2seconds", 2)
    .then(doComplete, doError);
promises[i++] = doAsync("fail", 8)
    .then(doComplete, doError);
promises[i++] = doAsync("3seconds", 3)
    .then(doComplete, doError);
// join promises
WinJS.Promise.join(promises)
    .done(function () {
        doProgress("all promises completed");
    }, doError);

Unlike chaining, joined promises should have their own error handlers.  If a failure happens in one of the promises, it will not stop the others in the join.

On a final note regarding promises, an error handler can be attached to WinJS.Promise.onerror. Do this as a safety net in addition to the methodologies covered so far.

End Gracefully

In summary, remember these useful guidelines and tips while you are writing your Windows Store app with JavaScript:

  • Errors happen – even in your code.
  • Error messages can be vague, so examine the context of suspicious code!
  • Trusting that your code should work is a bad idea.
  • Avoid common pitfalls by implementing a good type-checking strategy.
  • Handle the unhandled at the application level and page level.
  • Use error handlers appropriately when dealing with promises.

If you have not done so already, make sure you are getting all the latest resources by creating a profile at Generation App!!!

    Copyright © Microsoft Corporation. All rights reserved.
    The code provided in this post is licensed under the Microsoft Public License (Ms-PL).
Sep
12
2012

Microsoft DevRadio: Writing Code When the App Starts

To play video, hover above and press play button.

Abstract: win8genapp30
When does an application start in a blank and navigation template and where can you start writing your code for your app? Tune in for this helpful how-to from Michael Palermo

Next Steps:
Step #1 – Download Windows 8 and Windows 8 SDK
Step #2 – Download Visual Studio Express for Windows 8
Step #3 – Start building your own Apps for Windows 8

Subscribe to our podcast via iTunes, Zune, or RSS

If you're interested in learning more about the products or solutions discussed in this episode, click on any of the below links for free, in-depth information:

Websites:

Videos:

Virtual Labs:

    Copyright © Microsoft Corporation. All rights reserved.
    The code provided in this post is licensed under the Microsoft Public License (Ms-PL).

Resources

Archives

Team Blogs

Download OPML file OPML