Anthony Chu

Protractor is an end-to-end test framework for AngularJS. The official version is built on Node.js and Selenium WebDriverJS. While there is great support for NPM and task runners like Grunt and Gulp in Visual Studio (via extensions in VS 2013, and built into VS 2015), there is currently no way to integrate Protractor tests into Test Explorer (that I know of).

Thankfully there is Protractor.NET, a .NET port of Protractor built on top of Selenium WebDriver for .NET. It allows us to write Angular UI tests using .NET testing frameworks such as NUnit, and arguably produces more readable tests because there’s no need to use promises.

In ASP.NET, we typically store settings in web.config and sometimes in the database. It’s pretty trivial to access these values in server-side code, but what about in client-side JavaScript? We could store JavaScript configurations in a JSON file, but then we'd have configuration settings in different places and there is likely some duplication. Plus there is no easy way to create environment specific configurations like we can if the values were in web.config (using config transformations).

In my last couple of Angular projects, there needed a way for our Angular apps to access some values in web.config. To do this, I created an MVC view that returned a JavaScript containing Angular constant with the configuration values; and it’s worked really well.

Last fall, Microsoft released its Visual Studio Online editor, codenamed “Monaco”. It’s a powerful browser-based development experience built into Windows Azure Web Sites. It contains syntax highlighting for many languages, and first class language services for JavaScript and TypeScript. Monaco also includes Git integration and full access to the command line, including access to msbuild, npm, and nuget.

Today I used the Visual Studio Online editor to work on an issue for the fantastic DefinitelyTyped project. DefinitelyTyped is a repository of TypeScript typings for many JavaScript libraries.

When using AngularJS and Web API, sometimes AJAX calls don’t show up in Glimpse. It turns out there are a couple of configurations in AngularJS $http and Glimpse that need to be made.

Add Status Codes to Glimpse

By default, Glimpse only detects requests that return HTTP 200 (and maybe a couple of others). REST APIs (like ones created with ASP.NET Web API) often return 201, 202, and 204. These have to be added to the Glimpse configuration section in web.config…

<glimpse defaultruntimepolicy="On" endpointbaseuri="~/Glimpse.axd">
  <runtimepolicies>
    <statuscodes>
      <add statusCode="201" />
      <add statusCode="202" />
      <add statusCode="203" />
      <add statusCode="204" />
      <add statusCode="404" />
    </statuscodes>
  </runtimepolicies>
</glimpse>

With the release of .NET 4.5.1, we got new identity framework – ASP.NET Identity. Version 1.0 of ASP.NET Identity is pretty barebones… missing features such as confirmation of registration and password reset. Thankfully, the team has already released an alpha of ASP.NET Identity 2.0.

There is a lot that is new. Today, I’ll cover how to include the email address field on the registration page, and then allow the user to sign in with either their username or email.