It’s been a few months since our last roll-up of top developer stories, so I’ll be catching up with the news from last fall in two posts. We’ll start here in Part 1 with Visual Studio, .NET, ASP.NET, languages, and a few other tools for good measure. Part 2 will cover a variety of topics including Connect(); //2015, Windows 10, cross-platform development,. Visual Studio Code, and a number of other goodies. So let’s get started.

Visual Studio Update 1: almost like clockwork, John Montgomery announced the CTP (October), RC (November), and RTM (December) releases of Visual Studio Update 1. Among the complete list of features and changes that you can find on the Update 1 RTM Release Notes, and a few of the top features are as follows:

The C# Interactive Window and the command-line C# REPL window. (The Interactive Window is the REPL window inside Visual Studio.) For a quick demonstration, watch Kasey Uhlenhuth’s video on Channel 9 (11m 41s).
Edit and Continue support for /BigObj in C++, brings this powerful debugging feature to Windows Store C++ projects.
Go To Implementation: right-click on an interface or abstract method definition and navigate to its implementation:

Pull requests in the Team Explorer window through the Pull Requests hub, which shows your requests and those from others. Visual Studio Update 1 also improves the Create Pull Request experience so you can publish branches and create pull requests in a single action.

Profiling, remote Linux debugging, and IntelliTest: there has been some advance in a number of tools with Visual Studio 2015 that are worth calling out separately. First is the ability to profile your CPU in the debugger, as explained by Nikhil Joglekar, that lets you watch the CPU utilization graph to see if there is any CPU-intensive code running as you set breakpoints and step through code. In November, Marc Goodner shared the release of the Visual Studio GDB Debugger extension that enables debugging remote Linux targets including IoT devices. Pretty cool stuff, which even works on a Linux VM running in Azure! You can also read Prakash Patel’s post on Remote Debugging for JavaScript. Another fun extension is the Breakpoint Generator Extension, which automatically scans the source code in the active solution, finds the public methods (which are typical entry points to the program), and puts a breakpoint and a configurable trace message to the beginning of each method. Also very cool! And lastly, perhaps the coolest of all for developers with Visual Studio Enterprise Edition, is IntelliTest for .NET, which, as Pratap Lakshman explains in this post, helps you generate a whole suite of unit tests with a high degree of code coverage at a fraction of cost. You can also see a video demo in IntelliTest on Channel9 (34m 45s). Of course, this means you’ll run low on excuses for not unit-testing your .NET code. J

On the .NET front: The .NET Framework 4.6.1 announcement got plenty of attention with a variety of improvements, including some for WPF as explained also by Harikrishna Menon in his separate post. There’s also an interesting post by Omar Khudiera of Pangea Engineering called Why .NET? with some comparisons to Go and Java. Then we have the open-source, cross-platform .NET Core (now officially .NET Core 1.0) that is also gaining momentum, and the Introducing .NET Core video (7m 8s) by Richard Lander gives you the overview. .NET Core is also an integral component of Universal Windows apps in Windows 10, as explained in the short video .NET for UWP: CoreFx (3m 8s) by Lician Wischik. But that’s not all—because .NET Core can run on any platform, it’s also suitable for Linux, which means it can be used in Docker containers as well. Elton Stoneman explains this in Getting Started with .NET and Docker. With Docker, too, Adarsha Datta wrapped up a series on Docker: Containerize your Startup, the earlier parts of which we highlighted last summer.

ASP.NET: You may have just read on the ASP.NET blog (or Scott Hanselman’s) that ASP.NET 5 is now officially called ASP.NET Core 1.0 to go along with .NET Core 1.0 and Entity Framework 1.0 (which was Entity Framework 7). The naming change underscores the fact that the former “ASP.NET 5” was not a replacement for ASP.NET 4.6 and that we’re really entering a new space with the “Core” releases—“a fork in the road” as Hanselman describes it. That said, you’ll still find quite a few entirely applicable resources on “ASP.NET 5” including Scott Hunter’s video, Introducing ASP.NET 5 and Web Tooling (14m 51s), Dan Wahlin’s longer discussion in Modern Web Development (48m 8s), and Abhinaba Basu’s post, Publishing an ASP.NET 5 Web Application to IIS locally. And of course, fun things continue to happen in ASP.NET 4.6, such as WebHooks, as Scott Hanselman covers in Introducing ASP.NET WebHooks Receivers – Webhooks made easy. He also has a great post on simulating a low bandwidth connection.

C#, C++, TypeScript, and JavaScript: to wrap up the top news for Part 1, we have some fun items to share where languages are concerned. First, you can get a look ahead to C# 7 with this video by Mads Torgersen (58m 15s). If you’re writing C++, you’ll probably enjoy the session Writing Good C++14 from CppCon2015 (1h 42m) by none other than the master himself, Bjarne Stroustrup! And if you want be on the cutting edge of some C++ developments, check out the C++ Experimental Editor Tools, which you can turn on and off in Visual Studio 2015 as explained by Gabriel Ha. Heading over to the land of JIT, now, Bill Ticehurst has a video on What’s New in TypeScript (12m 7s) and David Catuhe shares two posts on Using JavaScript frameworks from your C#/UWP application and JavaScript goes to Asynchronous City, in the latter of which he shares the developments on promises in ECMAScript 6. Oh, and did you catch the news in December that Microsoft Edge’s “Chakra” JavaScript engine went open source? The repository itself just opened up here in January.

Finally, on behalf of everyone who has enjoyed working with and for Soma Somasegar, we wish you a fond farewell as you wrapped up 27 years of service at Microsoft! To enjoy a look back through his career and all the changes that have taken place during that more than a quarter-century, check out Mary Jo Foley’s exit interview with Soma. In one response he says, “I am a strong believer in developer choice and meeting developers where they are. Microsoft has been all about building great tools and platforms and letting developers make the choice of what they want to use and when.” That legacy, I know, pervades the work we do in Microsoft’s Developer Division, and will persist long into the future.
Thank you, Soma!

clip_image011

Kraig Brockschmidt, Senior Content Developer, Visual Studio
@kraigbro

Kraig has been around Microsoft since 1988, working in roles that always have to do with helping developers write great software. Currently he’s focused on developing content for cross-platform mobile app development with both Xamarin and Cordova. He writes for MSDN Magazine, is the author of Programming Windows Store Apps with HTML, CSS and JavaScript (two editions) and Inside OLE (two editions, if you remember those) from Microsoft Press, occasionally blogs on kraigbrockschmidt.com, and can be found lurking around a variety of developer conferences.

In Part 1 of this post I shared news from the fall on Visual Studio, .NET, ASP.NET, and languages. Here I’ll conclude the roll-up with news around Connect(); //2015, cross-platform development,. Visual Studio Code, Windows 10, and a little more.

Connect(); //2015: Our second Connect(); event was, to my mind, even more impressive than the first. I say this not just for the news and announcements, as John Montgomery reviews in his post, but for the way that all the demos tied together into one story that really illustrated the comprehensive platforms and tools that Microsoft is now delivering. Those demos were all built around a full health and technology scenario called HealthClinic.biz, the story of which Erika Ehril Cabral shares in her post from December. If you haven’t read that post yet, don’t deprive yourself any longer, because it also includes specific links to the exact demo segments in the Connect(); //2015 videos! Better still, the whole scenario is on GitHub so you can benefit from the work and also make contributions. And for just a bit of fun, take half a minute (OK, 35 seconds!) to enjoy Scott Guthrie get’s ready for Connect(); //2015.

Mobile and Cross-Platform Tools: work continues at a rapid pace on tools that help you develop mobile apps with Visual Studio. For Android directly, Marian Luparo talks all about Java debugging and language support in Visual Studio, and Mike James (on I Programmer) published a comparison between Visual Studio and Android Studio. The Visual Studio Emulator for Android team keeps delivering improvements too, and you can get the latest from John Kemnetz in his Connect(); //2015 video (5m 55s). Expanding to cross-platform tools for Windows, iOS, and Android, you can get an overview from Amanda Silver (3m 19s) and go into much more depth with Jeremy Foster, Varun Gupta, Ankit Asthana, and Jonathan Carter (54m 38s). In the latter you’ll hear about all the cross-platform tools including the Visual Studio Tools for Apache Cordova, Xamarin, Windows 10 UWP, and cross-platform C++. In this context, also check out Microsoft’s new Code Push service that enables Cordova and React Native developers to deploy mobile app updates directly to user devices, along with James Montemagno’s discussion on Xamarin.Forms 13m 4s) and the new Xamarin 4 release.

Java language support in Visual Studio

Windows 10 for Awesome Hardware: Windows 10 is certainly gaining momentum on a wide variety of systems, and Visual Studio clearly offers great tools for the Universal Windows Platform. What’s most fun to watch, though, is how Windows 10 is reaching onto new devices. Mark DeFalco and Nikola Metulev, for example, made a fun video on HoloLens + Lumia + Surface + Band + Windows 10 (24m 11s) that you can view on Channel 9. With the release of the Microsoft Band 2, there’s also an updated Band SDK that you can learn about from Maria Kang. And if you’re really just getting started, then try starting with Bob Tabor’s training series, Windows 10 development for absolute beginners. With dozens of episodes, you’ll learn everything you need!

Visual Studio Code: It’s quite enjoyable to see the evolution of this newest member of the Visual Studio family as it reaches many developers on non-Microsoft platforms. Sergiy Baydachnyy has been writing a whole series on Visual Studio Code for Mac developers, covering everything from installation and editor features to working with Git, deploying to Azure, and developing Cordova apps. I myself recently spend some time working exclusively in Visual Studio with Node.js, Express, MongoDB, and client-side AngularJS, and was impressed both by Code’s lightweight speed (it takes only a minute to install!) and its extensibility to support all kinds of different development scenarios. One key thing I learned: whenever you install a new package from npm, go right out and get the IntelliSense definitions via the tsd command. For web development too (and on a Mac), Robert Green shows you all the tricks in Visual Studio Code and Web Development (41m 52s).

U-SQL: The world of SQL is not necessarily where you expect to see new developments, but the introduction of U-SQL as a Big Data query language has attracted quite a bit of attention. Michael Rys first announced the language and its rationales in Introducing U-SQL – A Language that makes Big Data Processing Easy, and followed up with Writing and Using Custom Code in U-SQL. All this goes along with the public preview of the Azure Data Lake service, which is definitely work checking out if Big Data is on your radar.

And finally, for a bit of fun, developers of all sorts will appreciate Peter Wayner’s 9 bad programming habits we secretly love. I especially enjoyed the comments on goto because I did quite a bit of assembly programming early in my career where jump and branch instructions are just a way of life when you don’t have any higher-level concepts to work with. I imagine that some IoT developers working in assembly are thinking the same thing!

Kraig Brockschmidt, Senior Content Developer, Visual Studio
@kraigbro

Thousands of developers already use Visual Studio’s Tools for Apache Cordova—affectionately abbreviated as “TACO”—to build mobile apps for iOS, Android and Windows using a shared JavaScript codebase. Within the IDE, TACO provides everything you need to install and configure the native SDKs, preview your app, debug on emulators and devices, and even manage continuous integration/deployment via Visual Studio Team Services.

Today, we are pleased to announce new ways to build, debug and preview Cordova apps using your favorite light-weight text editor (it is your favorite, right?): VS Code and the Cordova Tools extension.

With this extension, you can debug hybrid apps, find Cordova-specific commands in the Command Palette, and use IntelliSense to browse objects, functions, and parameters. You can use it with both “stock” versions of the Apache Cordova framework and downstream frameworks like Ionic, Onsen, PhoneGap and SAP Fiori Mobile Client. Because they all use the same Cordova build systems and core runtime, the TACO extension is adaptable to the JavaScript framework of your choice.

In fact, you can even use Visual Studio Code on a project created with the full Visual Studio IDE. For example, imagine creating a Cordova project using Ionic templates with Visual Studio on a Windows machine, then opening it on an OS X or Linux machine using Visual Studio Code—making some edits—then continuing your work in the Visual Studio IDE. No matter which editor you choose, you get the full benefit of debugging, IntelliSense, and language support. How cool is that?

Visual Studio Code + Cordova Tools currently support debugging apps on emulators, simulators, and tethered devices for Android and iOS. If you ask for it (email or tweet us), Windows support will follow not too far behind. You can also attach the debugger to an app that is already running on a device; the debugger simply uses the application ID to locate the running instance.

How do I get it?

If you haven’t already, download and install Visual Studio Code for Mac, Windows or Linux from http://code.visualstudio.com. It’s under 50MB and on a decent network connection you’ll have it installed in under 2 minutes. Once that’s done, install the Cordova Tools extension directly from within the code editor. Simply invoke the Command Palette (Cmd+P on Mac, Ctrl+P on Windows), type “>ext install cordova”, and hit Enter.

You guessed it…open source!

You can, of course, contribute to improving the extension further. The Cordova Tools extension is open source, so if you run into any issues or have suggestions for new features, please open an issue or better yet, make the change and send us a pull request.

And last but not the least, we have also made some improvements in our command line tools and extensions for continuous integration optimizing your inner and outer dev loops!

Send us your feedback

We invite you all to join in our journey to grow an active community of Cordova developers to build amazing apps using TACO. Tell us what you’d like to see, and whether you are interested in testing pre-release versions of TACO. You can do this by joining our insiders program, posting issues on stack overflow, or pinging me directly via e-mail at rsalva (at) microsoft.com. We look forward to hearing from you!

Ryan Salva

Ryan J. Salva, Principal Program Manager, Visual Studio Client Tools team
Twitter: @ryanjsalva

Ryan is a Principal Program Manager working in the Visual Studio Client Tools team where he looks after HTML, CSS and JavaScript development. He comes from a 15-year career in web standards development & advocacy as an entrepreneur, developer, and graphic designer. Today, he focuses primarily on mobile app development using web technologies and Apache Cordova.

Today we’re releasing Visual Studio 2015 Update 1. Let me be the first to thank everyone who installed these earlier releases, provided feedback, and helped us iron out the kinks. [The final release of Team Foundation Server Update 1 is also available today, which you can read about on Brian Harry’s blog.]

I’ve already shared many of the features that we introduced in the CTP and the release candidate (RC), and you can find a complete list of features in Update 1 in the Visual Studio Update 1 RTM Release Notes. Let me now highlight the final additions made for RTM:

New Visual Studio Icon. Responding to your feedback on UserVoice, we’ve tweaked the Visual Studio 2015 icon in Update 1 to make it easier to differentiate visually between multiple versions of Visual Studio running side by side on the same machine:
.NET Framework 4.6.1. Visual Studio 2015 Update 1 includes the latest version (4.6.1) of the .NET Framework. You can read about all the new features on the .NET blog.
Editor support for new languages. The Visual Studio editor now provides built-in syntax highlighting and basic IntelliSense support for languages including Go, Java, Perl, R, Ruby, and Swift. We support the TextMate bundle
model for language grammars and snippets, allowing you to extend this with support for other languages.
IncrediBuild-Visual Studio partnership. With this collaboration and at no additional cost, developers can use IncrediBuild’s build engine to lay out build plans for their applications with more parallelized execution of the build. This leverages hardware resources more effectively and provides monitoring to identify bottlenecks and better understand resource usage. For complete details, see the post, Improving your build times with IncrediBuild and Visual Studio 2015.
Tools for Universal Windows Apps v1.2. This update enables you to build and submit apps to the Windows Store targeting Windows 10 SDK Version 1511. It includes several developer productivity improvements to .NET Native, the XAML designer, the manifest designer, Windows Store packaging, and the debugger in this release. If you don’t already have Tools for Universal Windows Apps installed, you can enable them by modifying the Visual Studio 2015 installation, or directly installing them from http://go.microsoft.com/fwlink/?LinkID=619614.
Native support for behaviors in Universal Windows apps. Behaviors are an easy way of adding common interactivity to your XAML apps without having to add more imperative code. These are natively supported in Update 1, shipping as a NuGet Package (available for both managed and native projects), and accepting contributions as an open source project. The package can also be installed through the Blend Assets Pane (under “Behaviors”). Learn more from the XAML Behaviors, open source and on UWP post on the Windows Developer blog, start contributing by visiting the GitHub page, or request features by raising issues.
MSTest and CodeCoverage support for ASP.NET 5. The Visual Studio testing tools now support MSTest framework-based tests for ASP.NET 5 applications and add support for CodeCoverage with ASP.NET 5 on x86/x64 platforms targeting the CoreCLR/CLR. The MSTest framework components are available from the NuGet gallery.
Parallel Test Execution: The Visual Studio testing tools introduce support for parallel execution of test cases leveraging the available cores on the machine, with Test Explorer indicating the progress of parallel tests. The test execution engine is launched on each available core as a distinct process, and is given a container (assembly, DLL, or relevant artifact) with the tests to execute according to the semantics of the test framework. VS supports parallel execution through all launch points (e.g. the command line and IDE commands like Test Explorer, CodeLens, and various “Run” commands). For details on how to enable this feature, refer to the Release Notes.
C# Interactive Window and command-line REPL. We’ve added more functionality and fixed a number of bugs in these features that first appeared in the CTP. For RTM we’ve also cleaned up some of the command-line argument handling as described in the detailed notes on GitHub. (Note that NuGet support and the VB scripting API are not available with this release, but we’re still actively working on them. In the meantime, you can play with the C# scripting API available on GitHub.)
Managing analysis issues. We’ve heard from many customers that when they install a Roslyn analyzer from NuGet or Visual Studio Extensions, thousands of code analysis issues end up showing up in the Error List, leading them to abandon the analyzer. With this update you can now suppress all current issues to a global suppression file, view and manage baselined issues (to audit suppressions or review baselined issues), show analysis warnings and messages for only ‘my code changes,’ and remove duplicate instances of warnings in the error list to focus results to the unique set.
NuGet and NuGet Package Manager. NuGet 3.3 is now bundled with Update 1, and we’ve made a number of changes to the NuGet Package Manager interface including a tab-based UI to help filter groups of packages, action buttons in the package list for quick access to common management functions, a Consolidate tab for packages you work with at the solution level, and an Update tab that allows you to select and update multiple packages together.
Visual Studio license improvements. Signing in to unlock the IDE with your subscription is one of those features that you do not want to see interrupting your workflow. Towards this goal, Update 1 has improvements that will ensure the IDE stays unlocked for a year or more after signing in as long as you have regular access to the internet to keep the license renewed in the background. More improvements to reduce sign ins are still to come.

Again, for a complete list of features in Update 1 and information on bug fixes and known issues, see the Visual Studio 2015 Update 1 Release Notes.

Your continuing feedback is very important to us as we now start work on the next Visual Studio update. Share your feedback, suggestions, thoughts, and ideas on UserVoice, through the in-product feedback UI, or file a bug through the Visual Studio Connect site.

John Montgomery is the Director of Program Management for Visual Studio, responsible for product design and customer success for all of Visual Studio, C++, C#, F#, VB, TypeScript, JavaScript, and .NET. John has been at Microsoft for 17 years, working in developer technologies the whole time. Reach him on Twitter @JohnMont

During Connect(); //2015 we showcased many technologies available to you as a developer across Azure, Office, Windows, Visual Studio and Visual Studio Team Services. We’ve also heard from you that you love to have real-world applications through which you can directly experience what’s possible using those technologies. This year, then, we built out a full health and technology scenario for our Connect(); //2015 demos and are delighted to share all the source code with you:

HealthClinic.biz is a fictitious regular doctor practice specialized in offering healthcare preventive care. This clinic is using different Microsoft and multi-channel apps built with Visual Studio 2015 to grow their business and modernize the customer experience. They also innovate and offer multiple apps and services—including websites, mobile apps, and wearable apps—to empower their patient’s well-being with easy access to manage their healthcare data and stay healthy.

How we built the scenario

We built eight different demo projects in a couple of months using Visual Studio 2015 and Agile methodologies. We used Visual Studio Team Services to host our code repository and to manage our backlog, daily builds, and DevOps cycle across a number of different teams at Microsoft. And all the data, services, and notifications that bring the experiences and devices together are centralized in a variety of Azure services. Here’s how all that is structured:

Connect (“with your health”); Demo apps

The core apps in HealthClinic.biz are a public website, a private website, a WPF application for receptionists, a Universal Windows Platform app for patients, mobile apps for patients and doctors, wearable apps, and more! The following sections give a brief summary of each, which you can see in action during the Connect(); //2015 keynotes.

Public and Private Websites

The clinic has a public-facing or marketing site that provides info on the services and apps that the clinic offers. The clinic is also an enterprise and needs to manage doctors and patients in its database. The clinic thus has a private website used for patient/doctor data management and a dashboard to understand visit trends.

Public website

Private website

We built both websites using Visual Studio 2015 + ASP.NET 5.0 RC + Azure, with Glimpse and App Insights for monitoring and gathering telemetry.

You can see these apps in action @ Scott Hanselman’s keynote starting at 2:11.

Universal Windows Platform and WPF apps

For receptionists, we built a WPF app that lets them view the information they need. Similarly, we build a Universal Windows Platform app for patients. Both apps use a common Portable Class Library that results in approximately 80% shared client logic code between the apps. You can see more during Kevin Gallo’s demo starting at 1:07:50.

WPF receptionist app

UWP patient app

Cross-platform mobile apps, and wearables

For patients, we built a cross-platform mobile app using Xamarin so we could deliver a native look and feel and great performance on every device across iOS, Android, and Windows.

We built another app for doctors of the clinic using web technologies and the Visual Studio Tools for Apache Cordova. This allows 100% code reuse across devices, with Cordova plugins providing access to native device capabilities not available in a browser.

Patient mobile app (Xamarin)

Doctor mobile app (Apache Cordova)

When patients want to schedule an appointment with their favorite doctor, they need to know when the doctor is available. These apps let patients create appointments in both the doctor’s Office 365 calendar and in their own Outlook.com calendar using same API, the Microsoft Graph API.

Of course, mobility is not only about smartphones and tablets. Wouldn’t it also be great if the doctors of this clinic could provide continuous service? Using Visual Studio 2015, we built an app that provides medication reminders for the Apple Watch and Microsoft Band 2 so patients can have assisted care throughout the day.

Watch Amanda Silver’s keynote talk and demo starting at 1:16:55 where she shows the latest on mobile development, including native cross platform apps (Xamarin), hybrid cross-platform apps (Cordova), and wearables.

Even more apps

During their segment, Brian Harry and Donovan Brown demonstrated (starting at 16:30) how Visual Studio Team Services plus different extensions work together to create an awesome DevOps experience for devices and services. And for the grand finale, Scott Hanselman showed a smart end-to-end diabetes monitoring scenario. He used multiple cloud technologies including health data from Microsoft Health, his own glucose data in the cloud, Azure Machine Learning experiment data, and the Microsoft Graph API to get insights from his own personal health data, such as determining the most stressful times in his calendar. Let’s just say the common thread had something to do with a man in a red shirt.

Download the code and contribute!

By now we hope you’re ready to get into the HealthClinic.biz code yourself, which you can download from GitHub. And we certainly invite you to help build out this scenario further to help many other developers realize solutions that can be built with the latest developer technologies to serve the many needs in our world today.

Download the code: HealthClinic.biz on GitHub

Enjoy!

Erika Ehrli Cabral, Senior Product Marketing Manager, Developer Tools

@erikaehrli1

Erika has been at Microsoft for over 11 years, working first in Microsoft Consulting and enjoying later on different roles where she created content and code samples for developers. In her current role she is now focused on executive keynote demos and Visual Studio and Azure product marketing.

Having just completed Connect(); // 2015, we thought to take a moment to review everything that’s happened with .NET over the last year, between last year’s and this year’s Connect();. And what a year it’s been! We’ve seen significant developments in the .NET Framework, including the release of new versions, and also the release of two new technologies, .NET Native and .NET Core, both of which will change the ways in which the .NET Framework is used and the platforms on which it is supported.

The .NET Framework 4.6

The .NET Framework version 4.6 was released in July with Visual Studio 2015 and is automatically installed on all Windows 10 systems. As the latest release of a mature product known for its robustness and ease of development, .NET Framework 4.6 offers improved app performance and a variety of individual feature enhancements:

A new version of the 64-bit JIT (Just-in-Time) compiler significantly enhances performance and supports SIMD hardware acceleration. A compiled app that targets x64 or anyCPU automatically takes advantage of the new JIT compiler when it runs on a 64-bit operating system.
Improved loading of assemblies decrease virtual memory.
Greater control over the garbage collector lets you disallow garbage collection during the execution of a critical path by calling GC.TryStartNoGCRegion and EndNoGCRegion. You can also use an overload of the GC.Collect method to control whether both the small object heap and the large object heap are swept and compacted or swept only.
The addition of SIMD-enabled vector types, such as Vector2, Vector3, and Vector4, Matrix3x2, and Matrix4x4, to the System.Numerics namespace.
Support for the Windows CNG cryptography APIs. The .NET Framework 4.6 adds the RSACng class to provide a CNG implementation of the RSA algorithm, a set of extension methods for X509 certificates, and enhancements to the RSA API so that common operations no longer require casting or type conversion.
Methods to convert the .NET Framework’s DateTimeOffset values to Unix time.
An AppContext class, which allows library developers to provide a uniform way for users of their application to opt out of new features.
Task-based asynchronous pattern (TAP) enhancements, including convenience methods to return completed tasks in a particular state (such as Task.FromCanceled) and a new class, AsyncLocal<T>, that allows you to store ambient data that is local to a particular asynchronous control flow. In addition, for apps that target the .NET Framework 4.6, tasks inherit the culture of the calling thread.
Improved rendering in Windows Presentation Foundation (WPF) and Windows Forms. WPF also has improved support for touch.
In Windows Communications Foundation (WCF), support for TLS 1.1 and TLS 1.2 in addition to SSL 3.0 and TLS 1.0. You can also select the protocol to use, or disable less secure protocols, programmatically, and you can send messages using different HTTP connections.

There are also enhancements in networking, Windows Workflow Foundation (WWF), transaction processing, and code page encoding. For a complete list of new features and additional detail, see What’s New in the .NET Framework.

The .NET Framework 4.6.1

The .NET Framework version 4.6.1 was released on November 30 and is automatically installed with the Windows 10 November Update. The .NET Framework 4.6.1 features performance and reliability improvements, as well as a handful of new features. As part of the ongoing work to modernize the cryptography API, the .NET Framework’s cryptography API now includes support for Elliptic Curve Digital Signature Algorithm (ECDSA) X509 certificates. In addition, Windows Presentation Foundation features spell-checking improvements and additional support for per-user custom dictionaries, while Windows Workflow Foundation now supports a distributed transaction manager other than MSDTC.

In-place and side-by-side upgrades

The .NET Framework 4.6 or 4.6.1 is an in-place upgrades for the .NET Framework versions 4.0, 4.5, 4.5.1, and 4.5.2. In other words, if any of those other four versions are already installed on a system, installing the .NET Framework 4.6 or 4.6.1 replaces them.

The .NET Framework 4.6 or 4.6.1 is a side-by-side upgrade for systems with any versions earlier than the .NET Framework 4 (the .NET Framework versions 1.1, 2.0, or 3.5); in other words, the .NET Framework does not replace these versions but instead is installed separately. Applications that target these older versions of the .NET Framework run on the older version if it is present. If the original targeted version of the .NET Framework is not present, they can instead run on the .NET Framework 4.6 if the following entry is made in the app’s configuration file:

<configuration>

<startup>

<supportedRuntimeversion=“v4.0“ />

</startup>

</configuration>

Application compatibility with .NET Framework 4.6 and 4.6.1

Will an application developed for an earlier version of the .NET Framework run under the .NET Framework 4.6 or 4.6.1? The .NET Framework maintains an extremely high level of backward compatibility from one version to another. Almost all applications that target the .NET Framework 4 and its point releases will run without modification on the .NET Framework 4.6 or 4.6.1. For a list of changes that may require recompilation, along with an assessment of their significance and possible workarounds, see Runtime Changes in the .NET Framework 4.6 and Runtime Changes in the .NET Framework 4.6.1. Some changes only affect apps that explicitly target the .NET Framework 4.6 or 4.6.1, but provide a different behavior for apps that target a previous version; for a list of these, see Retargeting Changes in the .NET Framework 4.6 and Retargeting Changes in the .NET Framework 4.6.1.

.NET Native

.NET Native is a compilation and deployment technology for Universal Windows Platform (UWP) apps written in C# and Visual Basic. It uses and optimized implementation of .NET Core (discussed in the next section) and compiles apps to native code. In other words, it compiles an app running on an ARM system to the ARM instruction set, and it compiles an app running on an x64 system to the x64 instruction set. This differs from most .NET Framework applications, which are compiled to intermediate language (IL) before they are deployed, and then are compiled to native code at runtime by the Just-In-Time (JIT) compiler.

.NET Native produces small, compact binaries that load and start up quickly. It statically links only those code elements from the .NET Framework Class Library and any other libraries you may use. Code paths that are not executed by your application are not linked into the binary. Along with your application code, .NET Native produces a small app-local runtime whose primary responsibility is memory management and garbage collection. For more information on .NET Native’s compilation technology, see .NET Native and Compilation.

Normally, the .NET Framework Class Library includes rich metadata about each assembly, type, and member. When compiling apps to native code, however, .NET Native includes only the metadata that an app actually needs at runtime. For some reflection and serialization scenarios, the .NET Native tool chain may be unable to detect that it needs specific metadata. You can identify these scenarios and ensure that the .NET Native tool chain includes all the necessary metadata at runtime by testing the release version of your app and defining the required metadata in a runtime directives file. In addition, two troubleshooters that help supply the runtime directives needed to reflect on or serialize types and type members are available.

By default, the release builds of all UWP apps written in C# or Visual Basic are compiled to native code with the .NET Native tool chain. For faster compilation and ease of debugging, however, debug builds are not compiled with the .NET Native tool chain. This makes it important to thoroughly test the release builds of your app on each of its target platforms.

For more information about creating UWP apps that are compiled to native code, see Getting Started with .NET Native.

.NET Core

.NET Core is a modular, cross-platform, open source implementation of the .NET Framework that will run on Windows devices, as well as on Linux and Mac OSX. Unlike the .NET Framework, .NET Core consists of a set of runtime, library, and compiler components that can be used in various configurations, depending on the needs of your application.

To get a better sense of what .NET Core is, let’s compare it to the.NET Framework 4.6:

.NET Framework	.NET Core
A sizable runtime, the CLR, that provides memory management and a host of other application services.	CoreCLR, lightweight runtime that provides basic services, particularly automatic memory management and garbage collection, to your app, along with a basic type library.
The .NET Framework Class Library, a large, monolithic library with thousands of classes and many thousands of members. Whether or not your application uses individual types and their members, they are always present and accessible.	CoreFX, a set of individual modular assemblies that you can add to your application as needed. Unlike the .NET Framework 4.5, where the entire .NET Framework Class Library is present, you can select only the assemblies that you need. That the assemblies are local to your application solves versioning problems and reduces the overall size of your applications. For example, if you are developing a vector-based application, you can download the System.Numerics.Vectors package without the overhead of a large class library.
Suitable for developing traditional Windows desktop applications.	Suitable for a full range of modern applications that operate on small devices with constrained memory and storage.

Aside from a basic setup procedure, each CoreFx module is independently downloadable as a NuGet package from the CoreCLR GitHub repo.

For more information on .NET Core, see Introducing .NET Core. For the basic .NET Core documentation set, see .NET Core: A General Purpose Managed Framework.

We hope you’ve enjoyed this recap of everything that’s happened in .NET over the last year. As always, we invite your feedback, suggestions, thoughts, and ideas on UserVoice, through the in-product feedback UI, or file a bug through the Visual Studio Connect site.

Ron Petrusha

Ron Petrusha is a programming writer on the .NET Framework team. He is also the author or co-author of a number of computer books, including Inside the Windows 95 Registry, VBScript in a Nutshell, and Visual Basic 2005: The Complete Reference.

As previously announced, Visual Studio has partnered with some of the most popular game engines to bring you an easy acquisition experience for game development tools. Today we are pleased to confirm that we now provide the ability to acquire and install the Unreal Engine directly from the IDE.

What is Unreal Engine?

The Unreal Engine is a cross-platform game engine targeting DirectX 11 and 12 for PC and Xbox, OpenGL for iOS, OS X and Android, and WebGL for the Web. Console development on Xbox One and PlayStation 4 is also available on the Unreal Engine for registered developers of those platforms. Unreal Engine also supports virtual reality development targeting platforms including Oculus, PlayStation VR, SteamVR and Gear VR.

Unreal Engine games can be programmed using C++ and Unreal’s visual scripting framework called Blueprints. Visual Studio serves as a powerful code editor and debugger when using C++ for Unreal development.

Unreal C++ code inside Visual Studio

Visual scripting with Blueprints

Getting Started

From Visual Studio you can open up the new project dialog using the FileàNew Project option and navigate to the installed templates, under which there will be a Game folder. Inside you will see the options that Visual Studio currently provides for creating a game, which now includes Unreal Engine. The Unreal Engine template will not appear if Unreal Engine is already installed on your machine.

Selecting this template will automatically launch a series of dialogs that will guide you through the Unreal Engine installation.

After selecting install, the Visual Studio installer will launch with the Unreal Engine checked. Click the Next button and you will be presented with a link to the Unreal Engine license, where clicking Update verifies that you have read and accept those terms and continues with the rest of the installation.

Gametime

One the installer has completed, the Unreal application will launch and you are now ready to start making games!

For more information on Unreal development, check out the following resources:

Getting Visual Studio Setup

Setting Up Visual Studio for UE4

Building Game Projects in Visual Studio

Unreal Development Docs

Get Started with UE4

Programming Guide

Cheers,

The Visual Studio Team @ Microsoft

Adam Welch

Adam Welch, Program Manager, Visual Studio Team

Adam joined Microsoft in 2012 after graduating college, fueled by his passion for software development and game design. He has worked on the Visual C++ debugging and diagnostic tools, including the native memory profiler, and more recently began focusing on game development tools for Visual Studio.

See Part 2 of this series.

Great apps—like great artists, actors, and athletes—are great performers. Human beings validate and continually improve their performances through extensive training, practice, rehearsals, and after-the-fact reviews. We achieve these same ends in software development through many levels of rigorous testing—or continuous validation—across the entire app lifecycle.

Chances are you’ve heard about unit testing, but you might not be clear on what it is, exactly, and how it fits into a cross-platform app project build with Apache Cordova. In the documentation for the Visual Studio Tools for Apache Cordova, we’ve recently added a whole section Author & run tests to explore the details of unit testing with Cordova apps through a series of comprehensive examples.

In this two-part post I’ll give a shorter version of those walkthroughs to familiarize you with the process. Part 1 here provides background on unit testing and a basic example with Cordova and Visual Studio. Part 2 will delve a little deeper into the subject of test-driven development and debugging unit tests.

Unit testing vs. other forms of testing

Unit testing is unique from other forms of manual and automated testing in a number of ways:

Unit Testing	Other Testing
Tests “units” of app code (classes, methods, properties, and functions) by calling/using them directly.	Tests the built app that’s been deployed to emulators or tests device through its user interface.
Is aware of how the app code is written (“white box testing”)	Is not aware of how the app was written (“black box testing”)
Tests are run on development and build machines via a test runner (for example, an independent JavaScript runtime like Node.js).	Tests are run on emulators or physical devices.
Tests are themselves pieces of code (typically written in the same language as the app code, e.g. JavaScript)	Tests are scripts (written manually or generated by a recorder) or are simply a set of steps that a tester performs manually.
Occurs early in the dev cycle, alongside coding or even before coding begins (test-driven development).	Occurs after a successful build of the app.
Ideally run very quickly so they can be performed with each build, which helps to quickly catch regressions introduced with code changes.	Are not time-sensitive (depending on one’s release management process)
Failed tests invalidate builds or commits to version control repositories.	Failed tests invalidate steps in a release management process.

The following figure illustrates how most forms of app testing (left) differ from unit testing (right), and illustrates that unit tests are typically run outside the app platform itself.

Note: when you set out to do unit testing, focus wholly on the code that you write or modify. You need not test libraries or other code you’re importing into a project but not modifying, as the authors of those libraries should have already tested them. If tests are lacking for a library you want to use, the right place to do that work is in the library’s source repo, not in your project.

Unit testing environments for JavaScript and Apache Cordova

A unit testing environment consists of the three components: the runtime, a test framework, and a test runner. The following table describes these and gives some examples.

Component	Description	Examples for JavaScript
Runtime	Loads and executes code being tested outside the app. This can happen in a browser or a separate runtime sometimes referred to as a “headless browser.”	Browsers, or Node.js, PhantomJS, Chrome V8
Test framework	Defines how to write pieces of code that are specifically identified as “tests,” typically in the same language as the code being tested so they can share the same runtime, but this is not required.	Jasmine, QUnit, Mocha along with libraries like Chai and assert.js
Test runner	Executes tests defined by a supported framework within a supported runtime, and produces test reports.	Chutzpah (uses PhantomJS), Karma (uses a browser)

All of these relationships are illustrated below:

Unit testing is then a matter of invoking the test runner at appropriate times and viewing the reports. This can be done manually or as part of an automated build process, and the test runner might be invoked through the command line or through integration with the Visual Studio IDE.

Some test runners, like Chutzpah, have a Visual Studio test adapter that integrates the tool and its reporting into Visual Studio’s Test Explorer. Other test runners, like Karma, don’t have a test adapter but can still be integrated into Visual Studio’s Task Runner Explorer in conjunction with tools like Grunt and gulp. Both options are covered in the documentation; for Karma and gulp, see Basic unit testing and Test Apache Cordova apps with Karma and Jasmine.

Unit testing in action

To better understand the mechanics of unit testing, let’s now follow a piece of code and an associated unit test through the basic process with Chutzpah, QUnit (jQuery’s unit test framework), and Visual Studio.

The “unit”

First, assuming you have the Visual Studio Tools for Apache Cordova installed, create a new app project through File > New Project, selecting JavaScript > Apache Cordova Apps > Blank App. Then in the www/scripts folder create a file called normalize.js with the code below.

/** @description Converts JSON data that may contain Name and PersonalIdentifier
 *    properties to an object with the properties name (string) and id (positive
 *    integer up to 9999999999.
 * @param {string} jsonIn The JSON data to normalize.
 * @return {object} An object with name (string) and id (integer) properties,
 *    defaulting to "default" and 0, or null if the JSON is null or invalid.
 */
function normalizeData(jsonIn) {
}

This simple normalizeData function is the “unit” we’ll be testing, and we’ll leave it empty for the moment. Understand that this code is strictly part of the app’s functionality: it has nothing whatsoever to do with our choice of test framework or test runner.

The unit tests

Next, each unit test is a piece of code that validates a unit by:

Calling it with specific inputs, and,
Checking the output against the expected value.

A unit test must follow the conventions of the test framework you’re using. Because we’re testing JavaScript code, it’s easiest to use one of the many JavaScript test frameworks available to us. For this example, we’ll use the one called Jasmine. It enjoys built-in support with the Chutzpah test runner that we’ll be using shortly, so we don’t need to install anything for Jasmine specifically.

For the unit tests, create a folder named test in the project, then create a file in that folder called normalize_tests.js with the following contents:

// First argument to "describe" is the name of this group of tests
describe("normalizeData tests", function () {
    // First argument to "it" is the name of the specific test
    it("accepts golden path data", function () {
        // Use the unit being tested as necessary
        var json = '{"Name": "Maria", "PersonalIdentifier": 2111858}';
        var norm = normalizeData(json);

        // Check the results; "expect" is a Jasmine method.
        expect(norm.name).toEqual("Maria");
        expect(norm.id).toEqual(2111858);
    });
});

In Jasmine, you create a group of tests with its describe method, and each test is a call to a function named it, which ends up reading quite well with the description of the test itself. Within each test you use the unit code however you want, and then check results with Jasmine’s expect method that generates the appropriate pass/fail report output.

We have just one simple test to start with here, but notice how it’s specific: it calls the unit under test with one set of inputs and gives an exact name/description for the test with those inputs. This follows the best practice of isolating each unit test to an individual test case, creating a 1:1 mapping between the name of the test, as it appears in reports, and the exact test case (that is, the arguments used in the test). When the test runner reports a failure, then, you know exactly where to look in your code and can easily step through that one test in the debugger to isolate the failure. This saves you time in the end, because if you combine tests, you’ll have to debug the whole set to find the one that failed, and you’ll likely end up separating all the tests anyway.

The test runner

With unit code and at least one unit test in place, we can now run the tests with the Chutzpah test runner. To install it, go to Tools > Extensions and Updates… in Visual Studio, select Online, then search for and install the “Chutzpah Test Adapter” (you’ll be prompted to restart Visual Studio):

To tell Chutzpah about the files it should work with, create a Chutzpah.json file in the project’s root folder with the following contents:

{
  "References": [
    { "Path": "www/scripts/js/normalize.js" }
  ],

  "Tests": [
      { "Path": "test/normalize_tests.js" }
  ]
}

The “References” section clearly identifies the code to test and the “Tests” section identifies the unit test files. You’d obviously list more code and test files as you add them to a project.

Now select Test > Windows > Test Explorer and you should see the available tests listed there:

Note: if nothing appears, there are likely syntax errors in your test files which prevent Chutzpah from finding those tests.

Click Run All to build the project, run the tests, and see the results. Because we don’t have any implementation in normalizeData, the test should fail:

This verifies that you have the mechanics of using Chutzpah working within Visual Studio.

If you’d like to make the test pass, implement normalizeData so it at least handles expected inputs and run the test again:

function normalizeData(jsonIn) {
    data = JSON.parse(jsonIn);
    return {
        name: data.Name,
        id: Number(data.PersonalIdentifier)
    };
}

Of course, this code can’t handle anything other than perfect JSON, so there’s definitely room for improvement! We’ll pick up that story in Part 2 where we’ll talk about test-driven development and debugging unit tests.

In the meantime, I’d love to hear how you work with unit testing in Cordova apps, how you’re working with UI testing (both manual and automated), and how we can further improve our support through the Visual Studio Tools for Apache Cordova. Add a comment below, drop me a line at kraigb (at) microsoft.com, or submit suggestions via http://visualstudio.uservoice.com/.

Happy testing!

See Part 2 of this series.

clip_image010

Kraig Brockschmidt, Senior Content Developer, Visual Studio

@kraigbro

Part 1 of this post provided some background on unit testing with a basic example in Visual Studio for an app written with Apache Cordova. In this post we’ll make many improvements to that example using the process of test-driven development, which helps you separate the process of thinking about how to challenge a unit of code to fail from the process of coding that unit to make it not fail! We’ll also discuss a little about debugging unit tests.

Again, these two posts are a shorter version of walkthroughs that we’ve recently added to the documentation for the Visual Studio Tools for Apache Cordova, in the section Author & run tests.

Test-driven development

It should be obvious that having one test for an empty (or overly simplistic) implementation of normalizeData is woefully inadequate. A robust normalizeData needs to handle all sorts of bad JSON that would cause utility functions like JSON.parse and/or property dereferences to fail. And of course we need to have tests that exercise all the data variations we can think of.

Question is, where to start? Write code, write tests, or go back and forth between the two? You’ve probably done plenty of the latter: write some better code into normalizeData, then write some tests, examine cases that fail, then write more code, write more tests for cases you haven’t covered yet, correct the code again, and so on. Although this is manageable, it forces you to switch back and forth between thinking about code and thinking about data, and switching between trying to make the code work properly and thinking up ways to make it fail. These really are two different mental processes!

This is where the approach of test-driven development shows its value. To fully exercise any piece of unit code, you eventually have to think through all the necessary input variations. Test-driven development does this thinking up front, which is very efficient because once you think of a few tests cases, you can quickly see additional ones. For example, if you think to include an object inside a piece of JSON, you’ll naturally think to include an array as well. If you think to include an integer where the unit code might expect a string, it’s natural to also try a string where it expects an integer.

With the normalizeData function, I found it took perhaps 15 minutes to think through a strong set of test inputs with different challenges to JSON.parse, challenges to assumptions about the structure of valid JSON, and challenges to assumptions about data types. Here’s that list:

'{"Name": "Maria", "PersonalIdentifier": 2111858}'
null
''
'blahblahblah'
'{{}'
'{{[]}}}'
'document.location="malware.site.com"'
'drop database users'
'{"Name": "Maria"}'
'{"PersonalIdentifier": 2111858}'
'{}'
'{"name": "Maria", "personalIdentifier": 2111858}'
'{"nm": "Maria", "pid": 2111858}'
'{"Name": "Maria", "PersonalIdentifier": 2111858, "Other1": 123, "Other2": "foobar"}'
'{"Name": "Maria", "PersonalIdentifier": "2111858"}'
'{"Name": "Maria", "PersonalIdentifier": -1}'
'{"Name": "Maria", "PersonalIdentifier": 123456789123456789123456789123456789}'
'{"Name": , "PersonalIdentifier": 2111858}'
'{"Name": 12345, "PersonalIdentifier": 2111858}'
'{"Name": {"First": "Maria"}, "PersonalIdentifier": 2111858}'
'{"Name": "Maria", "PersonalIdentifier": {"id": 2111858}}'
'{"Name": {"First": "Maria"}, "PersonalIdentifier": {"id": 2111858}}'
'{"Name": ["Maria"], "PersonalIdentifier": 2111858}'
'{"Name": "Maria", "PersonalIdentifier": [2111858]}'
'{"Name": ["Maria"], "PersonalIdentifier": [2111858]}'
'{"Name": "Maria", "PersonalIdentifier": "002111858"}'
'{"Name": "Maria", "PersonalIdentifier": 002111858}'

Again, once you get thinking about input variations, one test case naturally leads to another. And once you’ve worked out JSON variations for one unit test, you’ve essentially created a reusable asset for any other function that takes JSON, in whatever project.

With the input list in hand, it’s now a simple matter—with a lot of copy and paste!—to wrap the necessary test structure around each set of inputs. For example:

it('accepts golden path data', function () {
    var json = '{"Name": "Maria", "PersonalIdentifier": 2111858}';
    var norm = normalizeData(json);
    expect(norm.name).toEqual("Maria");
    expect(norm.id).toEqual(2111858);
});

it ('rejects non-JSON string', function () {
    var json = 'blahblahblah';
    var norm = normalizeData(json);
    expect(norm).toEqual(null);
 });

it('accepts PersonalIdentifier only, name defaults', function () {
    var json = '{"PersonalIdentifier": 2111858}';
    var norm = normalizeData(json);
    expect(norm.name).toEqual("default"); //Default
    expect(norm.id).toEqual(2111858);
});

it('ignores extra fields', function () {
    var json = '{"Name": "Maria", "PersonalIdentifier": 2111858, "Other1": 123, "Other2": "foobar"}';
    var norm = normalizeData(json);
    expect(norm.name).toEqual("Maria");
    expect(norm.id).toEqual(2111858);
});

it('truncates excessively long Name', function () {
    //Create a string longer than 255 characters
    var name = "";
    for (var i = 0; i < 30; i++) {
        name += "aaaaaaaaaa" + i;
    }

    var json = '{"Name": "' + name + '", "PersonalIdentifier": 2111858}';
    var norm = normalizeData(json);
    equal(norm.Name).toEqual(name.substring(0, 255));
    equal(norm.Name.length).toEqual(255);
    expect(norm.id).toEqual(2111858);
});

it('rejects object Name and PersonalIdentifier', function () {
    var json = '{"Name": {"First": "Maria"}, "PersonalIdentifier": {"id": 2111858}}';
    var norm = normalizeData(json);
    expect(norm).toEqual(null);
});

Note that the test names (the first argument to it) are what appear in UI like Test Explorer, so they should always identify what’s being testing and the basic nature of the test (e.g. “rejects” or “accepts”). Also, it’s certainly possible to put inputs and expected results into an array and iterate that collection instead of writing each test individually. I’ve just left everything explicit here.

The point here is that by first spending something like 30 minutes of focused work on input variations and wrapping them in unit tests, you’re now entirely free to focus on writing the code without having to wonder (or worry!) whether you’re really handling all the possible inputs.

In fact, if you run all these tests against an initially empty implementation of a function like normalizeData, many or most of them will clearly fail. But that just means that the list of failed tests is your to-do list for coding, mapping exactly to the subset of input cases that the function doesn’t yet handle properly. You improve the code, then, to pass more and more tests. When the function passes all the tests, you can be completely confident that it can handle all the possibilities it should. For a full walkthrough, which includes the completed implementation of normalizeData, see Improving the unit tests: an introduction to test-driven development in the documentation.

Test-driven development, in short, cleanly separates the task of coming up with input cases from the task of writing the code to handle those cases. Ultimately, if you’re going to do a really good job testing your code, you’ll have to separate these tasks one way or another. By acknowledging this up front, test-driven development can result in more robust code earlier in the development process, which can reduce your overall costs.

Debugging tests and runtime variances

One of the unit tests shown in the previous section is buggy. Do you see which one? I thought I’d written a complete implementation of normalizeData, which included code to handle the 'truncates excessively long Name' test case, but that case was still failing and I couldn’t see the problem right away.

Fortunately, Visual Studio gives you the ability to debug unit tests just like you can debug any other kind of code, with the ability to set breakpoints, examine variables, and step through the test code. Unit test code is still code, after all, and just a prone to bugs!

Setting breakpoints in the Visual Studio editor isn’t enough, however. Running tests through Test Explorer doesn’t pick up those breakpoints because a test runner like Chutzpah is spawning separate PhantomJS processes to load and execute all the JavaScript, but the Visual Studio IDE doesn’t have debug hooks into that engine.

You have instead use the Test > Debug > Run menu, where you’ll find options for Selected Tests and All Tests. You can also right-click a failed test and select Debug Selected Tests. Any of these commands will, for JavaScript, instruct the test runner to execute code in a browser, to which Visual Studio can attach the debugger. Reports from the test framework will also appear in the browser.

Gotcha alert! The Test > Debug > Run > All Tests and Test Explorer > Run All commands automatically save any files that you’ve modified in the project. However, commands that run individuals tests, do not save changed files, which can lead to some confusion when an expected change isn’t picked up. So be sure to save prior to running individual tests.

In the debugger, I was able to see that my unit test mistakenly tries to dereference norm.Name rather than norm.name:

After this fix I had just a single remaining test to satisfy, one that tested having a leading zero on an integer value in the JSON. I wasn’t sure why it was failing, so I started the debugger for that test as well. But in the debugger, the test passed! What was going on?

Turns out that I found a small difference between the implementation of JSON.parse in the PhantomJS runtime, which was used when running tests outside the debugger and throws an exception with the leading zero, and the Internet Explorer runtime, which was used during debugging and is just fine with the leading zero. See the topic Debugging unit tests in the documentation for that story!

What’s important to keep in mind here, is that you may find a few similar differences between the runtime used for unit testing and the platform runtime used when the app runs for real. For this reason it’s a good idea to occasionally run all your unit tests on each mobile platform. To do this, adding a special page to a debug build of your app that runs tests when you navigate there. In this case, the act of navigation serves as the test runner, and you’ll need to explicitly reference the test framework libraries so that they’re loaded for that page.

Closing

That wraps it up for parts 1 and 2 of this post, which is again a shorter version of content that we’ve published in the Author & run tests section of the documentation. There you’ll find more detailed walkthroughs, along with a discussion about using “mocks” to handle calls to platform APIs and other external dependencies that the unit testing runtime won’t have access to. Let us know what you think!

I’d also love to hear how you work with unit testing in Cordova apps, how you’re working with UI testing (both manual and automated), and how we can further improve our support through the Visual Studio Tools for Apache Cordova. Add a comment below, drop me a line at kraigb (at) microsoft.com, or submit suggestions via http://visualstudio.uservoice.com/.

Happy testing!

clip_image010

Kraig Brockschmidt, Senior Content Developer, Visual Studio

@kraigbro

Welcome to the new year and a new Visual Studio Tools for Apache Cordova (TACO) update! We just released Update 5 of the tools for you—full details are in the release notes—and we’ve created a new developer blog that you can follow to keep up to date with tips, tricks, and articles from our development team.

New in Visual Studio TACO Update 5

In Visual Studio 2015, you should see a prompt to download and install the new Visual Studio TACO Update 5 release.

The top changes in this release are:

CLI interop. If you switch between the command line and Visual Studio, your changes reflected in both development environments.
Node 5 / NPM 3 and Cordova 5.4.1 / 6 compatibility. Right now, NPM 3 does not work with Cordova versions 5.3.x and lower. In Update 5, if you are targeting a Cordova version older than 5.4.0 and you have NPM 3 or higher, we will fail your build and show you an error message with suggestions for fixing your build.
Over 50 bug fixes. These address issues such as supporting the iOS 6s simulator, various Ripple deployment matters, and support for MySQL.

Read more from our developers, or go to the release notes for Update 5.

Keeping in touch with you!

In addition to building out our tools, we’ve also been working on a few new ways to connect you with members of our team—to help you master the tools and move past issues blocking you from completing your projects.

New developer blog. We’ve just released a new Visual Studio TACO Developer Blog to which we’ll share out regular topics from our engineering team – including tips, tricks, and “behind the scenes” topics.

Cordova Tools Live Stream. We’re also continuing the Cordova Tools Live stream that we announced last November. In the months ahead, we’ll continue to have regular question and answer sessions with the community. We’ll also be expanding to include a regular set of interviews and topics of interest to Cordova developers at large. Finally, you’ll see us step up the video and audio quality dramatically with the help of our friends at Channel 9.

Visual Studio TACO Newsletter. In order to keep you updated on all the new samples, tutorials, and guides we are coming out with, we have started a Visual Studio TACO Newsletter with helpful tips on the topics we find you all are asking about. Sign up here and look for the first issue in late January!

Lina Zhong

Linda Zhong, Program Manager, Visual Studio Client Tools Team

Linda is new to the Tools for Apache Cordova team, but not new to the trials and tribulations of sad documentation. She spends her time thinking about how to make the VS Cordova user experience really rock!

Jordan Matthiesen

Jordan Matthiesen (@JMatthiesen)
Program Manager, Visual Studio Tools for Apache Cordova

Jordan works at Microsoft on JavaScript tooling for web and mobile application developers. He’s been a developer for over 18 years, and currently focuses on talking to as many awesome mobile developers as possible. When not working on dev tools, you’ll find him enjoying quality time with his wife, 4 kids, 1 dog, 1 cat, and a cup of coffee.

The C# Interactive Window and the command-line C# REPL window. (The Interactive Window is the REPL window inside Visual Studio.) For a quick demonstration, watch Kasey Uhlenhuth’s video on Channel 9 (11m 41s).
Edit and Continue support for /BigObj in C++, brings this powerful debugging feature to Windows Store C++ projects.
Go To Implementation: right-click on an interface or abstract method definition and navigate to its implementation:

Pull requests in the Team Explorer window through the Pull Requests hub, which shows your requests and those from others. Visual Studio Update 1 also improves the Create Pull Request experience so you can publish branches and create pull requests in a single action.

clip_image011

Kraig Brockschmidt, Senior Content Developer, Visual Studio
@kraigbro

Java language support in Visual Studio

Kraig Brockschmidt, Senior Content Developer, Visual Studio
@kraigbro

How do I get it?

You guessed it…open source!

And last but not the least, we have also made some improvements in our command line tools and extensions for continuous integration optimizing your inner and outer dev loops!

Send us your feedback

Ryan Salva

Ryan J. Salva, Principal Program Manager, Visual Studio Client Tools team
Twitter: @ryanjsalva

Ryan is a Principal Program Manager working in the Visual Studio Client Tools team where he looks after HTML, CSS and JavaScript development. He comes from a 15-year career in web standards development & advocacy as an entrepreneur, developer, and graphic designer. Today, he focuses primarily on mobile app development using web technologies and Apache Cordova.

Earlier this summer, the Visual Studio Tools for Apache Cordova moved to an open documentation model to engage developers like you to help create an amazing hybrid mobile app development experience. We believed at that time that Apache Cordova was the future of mobile development, and we believe it now as we continue investing our efforts into transitioning web developers into high-quality mobile app makers.

Part of Microsoft’s contribution to the Cordova community is the Visual Studio 2015 Tools for Apache Cordova. To give you the best possible experience with our product, we documented our tools on both the Cordova Docs Github repo, and on the MSDN site. However, having two sources of documentation has quickly become confusing and redundant. Moreover, retaining proprietary control over some documentation ill-matches our commitment to working with the open-source community.

With those concerns in mind, we have decided to move all documentation onto one central site, taco.visualstudio.com. Our process takes articles from our GitHub repo (which now contains all MSDN docs) and processes them into a sleek and navigable website.

Let’s take a tour

You can access the new site from the URL directly (http://taco.visualstudio.com/), or from the documentation link on the Cordova tools product page.

Documentation link on visualstudio.com

This link lands you on our new home page that contains all of the content that has existed on MSDN:

Home page for Visual Studio Tools for Apache Cordova documentation

A new onboarding guide for Cordova and VS beginners

In addition to existing content, the site itself features a new Beginner’s Guide in the Get Started section. This guide takes you from installation to completion of your first app, and hopefully inspires you to start exploring hybrid app development. We hope that you check it out and give us your feedback!

Getting started guide for Visual Studio Tools for Apache Cordova

Sourcing community knowledge

Speaking of feedback, each article contains a comments section where you can leave behind thoughts, feedback, questions, etc.

If you have a specific change or addition you’d like to see, we invite you to contribute to our Github repo. If you find any issues with the docs or have suggestions for new ones, please open an issue or better yet: send us a pull request. (Learn more on how to create a pull request on GitHub request on GitHub.)

If these don’t do it for you, share your feedback directly with the product team viaUserVoice, Send-a-smile, Twitter, StackOverflow, or email (vscordovatools-at-microsoft dot com).

Big plans, big future

Check back often for new content and information on our site. Periodically we will be updating the site with new walkthroughs, tutorials, and samples. We hope to make this your one-stop shop for Cordova app development.

With new developments being released regularly, soon there will be a huge array of amazing features that can help you build a beautiful mobile app using web technologies. We’re working hard over here, so stay in touch.

Linda Zhong

Linda Zhong, Program Manager, Visual Studio Client Tools Team

Linda is new to the Visual Studio Client Tools team, but not new to the trials and tribulations of sad documentation. She spends her time thinking about how to make the VS Cordova user experience really rock!

Microsoft is a developer company, so there’s nothing we love more than connecting with developers to share our latest tools, technologies and plans for the future. I therefore invite you to set your calendar for November 18-19 for Connect (); // 2015– when Microsoft hosts its premier fall developer event, streamed live and for free, from New York City to developers around the world.

Keynotes and technical sessions will feature news, demos and insights that illustrate how developers are working with Microsoft to capitalize on their evolving roles with powerful and flexible tools that embrace today’s open environments to target Android, iOS, Linux, Windows and more.

This year’s event will demonstrate the tremendous progress we’ve made on the journey toward a new Microsoft for developers that began last year with the announcements of a cross-platform .NET for Linux and OSX available as open source and the new Visual Studio Community edition for targeting nearly every major device and OS, available for free.

Scott Guthrie; Brian Harry, Scott Hanselman, Amanda Silver, Anders Hejlsberg and Beth Massi and many more

Connect(); will feature a marquee lineup of speakers joining Scott Guthrie to talk code, including; Brian Harry, Scott Hanselman, Amanda Silver, Anders Hejlsberg and Beth Massi alongside many of the customers, partners and industry luminaries who are leading the shift toward mobile first, cloud first computing scenarios.

We encourage you to save the date and tune in November 18^thand 19^th, visit our event website below and save the date.

Save the date, visit:http://www.visualstudio.com/connect2015

Thank you,

Mitra

Mitra Azizirad, General Manager, Developer Platform Marketing

With an expansive technical, business and marketing background, Mitra has led multiple and varied businesses across Microsoft for over two decades. For the last three years, she’s led the Developer Platform Marketing and Sales team, including Visual Studio Product Marketing.

In this blog we typically share updates and improvements to Visual Studio itself. We also want to highlight examples of how developers use these tools to build compelling mobile apps.

Meet Sverre Nøkleby, a developer from Norway who’s been building the very cool WeatherPerfect app using Apache Cordova. I interviewed him recently over Skype and email. Among other things, we discussed how he built the app and his recommendations to developers that have a great new app idea they want to bring to reality.

Meet Sverre and WeatherPerfect

Tell me a little about your app. What prompted you to build it?

As a runner with a family and full time job, I often struggle with finding time to run. And where I live (Bergen, Norway) we have a lot of rain, which I would like to avoid when being outdoors. My wife and I pretty much organize our lives using shared calendars, so I ended up switching between the calendar and the weather forecast to find a good time to run. To make this process easier, I built WeatherPerfect. It is an app that combines the weather forecast and the user’s calendars to find the best time to run.

How long have you been developing software?

Professionally since 2002; as a hobbyist I started with Turbo PASCAL 1995. I've been involved in all layers of the [web development] stack at some point, with a focus on front-end development the last years. The last 5 years I’ve been using ASP.NET MVC. I’ve also been doing hobby-projects involving web-sites for around 10 years now. I also built tagdef.com, which has been reasonably popular and now has over 70,000 user-added definitions of hashtags.

What’s your background with mobile development?

I [built] an iPhone app a couple years ago with native iPhone development using Objective-C. I made a super simple Android app, as well. [WeatherPerfect] was my first take on using [Apache] Cordova.

Also, the web development I've done the last 2-3 years has taken mobile into account. We were the first bank in Norway to completely replace our "mobile bank" with a responsive web app.

Why did you decide to use Visual Studio?

There were multiple reasons. Because I’m an Android-user, I decided to target this platform first. But Android Studio and the Android emulator runs really slow on my old computer. I tried using it, but it got frustrating quickly. Visual Studio 2015 was out as a release candidate, and I had read that it supported multi-platform development using Cordova. It also turned out to run smoothly on my old PC.

Using Visual Studio and Cordova meant that I could develop in an environment and technology I’m familiar with. I’m pretty sure being able to use HTML5 and debugging in the browser gave me a flying start, compared to native development.

Why did you choose to build an application using Cordova?

[I’ve] been building web applications for 5 years, so the technology was very familiar to me. I didn't have to learn the Java/Android stack.

I didn't have to spend extra money beyond hiring a designer. The tools were free. Even though I chose to target Android first, the possibility to target other platforms without a total rewrite is a nice bonus.

Going from idea to published app

How long did it take you to build your application?

It took about two months from idea to publishing the app in the Google Play Store. I spent evenings and weekends to assemble the app in my spare time.

I tried to also allocate time to doing stuff we coders often ignore: making proper screenshots for the app-store, doing some user testing, trying to figure out a way to make the app known to the world, etc. I guess the fancy word for much of this is "App store optimization."

What was your development process like?

Even though web development in general is familiar ground, I decided to use this project as a way of learning some new technology or library. So this was the first time I used ReactJS in a real project.

I started with the key functionality: Fetching the weather forecast from a REST API, rating the different time period based on preferences, and fetching items from the user’s calendars from the phone.

I got external help on the design. The design was delivered as PDF, but the designer also provided CSS for the basic components, colours, fonts etc. This made the transfer from PDF to app much easier.

I did most of the initial testing and debugging directly in the browser on my computer. This meant I could adjust the GUI directly with the developer tools, edit code and run it instantly, and in the worst case edit code in Visual Studio and hit F5 in the browser. […] When the app got a bit more complex, I also used the browser for performance profiling.

A bit into the development process, I started testing more on real devices. I used an online tool [called TestObject] for this, which gave me access to all sorts of devices. I also used [the NodeUnit] library to add unit tests.

I set up Gulp in Visual Studio [to compile TypeScript, generate JavaScript from .jsx files, compile LESS and SCSS, and run unit tests].

What was the most difficult part of building your app and how did you overcome that challenge?

Making the app look like a native Android app with material design.

Perhaps this is due to my mediocre CSS skills, but you can still tell that the app behaves a bit different from a native app with material design. For example, when sliding between tabs, WeatherPerfect doesn’t have the smooth transitions that good native apps have. I honestly don’t know if this is something you get out of the box with native development, but this was one thing that I just had to cut in the initial version. I focused on making the GUI fast, and used some of the many CSS libraries and code-examples that emulate the material design look.

I ended up using very little external JavaScript and CSS for that. I was in the lucky position that my designer had made a design that followed many of the material design guidelines, and provided me with the CSS for colours and shapes. Again, a nice feature with Cordova is that CSS is a universally known design language.

Advice for other developers

For developers new to Cordova development, what advice would you give?

Try to identify the deal-breakers early on. If you are accessing native OS functionality, are there Cordova plugins available for the platforms you target? If not, it might not be many lines of code to make the plugin yourselves. I made a plugin for better geo-location on Android with very little Java or Android specific knowledge.

Remember that even the newest phones are much slower than your desktop computer. So keep an eye on JavaScript performance. Modern browsers have great support for debugging this.

If you get an error on a physical device that you cannot reproduce using the emulator on the computer, remember that you can attach the phone to the computer and do remote debugging from the browser.

What learning materials/sites did you use while building your app?

99designs.com for hiring a designer
testobject.com for testing the app on many different devices
The material design guidelines
Visual Studio Tools for Apache Cordova documentation
Thousands of web searches and hundreds of visits to stackoverflow.com :)

Wrapping up

A huge thank you goes to Sverre, for taking the time to share with me his experience and advice for Cordova developers! You can follow along with the WeatherPerfect app now by downloading it for Android devices and follow Sverre on Twitter.

I hope you found this interview interesting as we discussed the creation of the WeatherPerfect app using Visual Studio TACO. If you have an app you’d like to share with us, let us know by tweeting us on Twitter (@VSCordovaTools) or email us with your suggestion (vscordovatools –at- microsoft.com)!

Sverre Nøkleby (@MrCalzone)
Software Architect, creator of WeatherPerfect

Enjoys running and beer, but not at the same time.

Jordan Matthiesen (@JMatthiesen)
Program Manager, Visual Studio Tools for Apache Cordova

Jordan works at Microsoft on JavaScript tooling for web and mobile application developers. He’s been a developer for over 17 years, and currently focuses on talking to as many awesome mobile developers as possible. When not working on dev tools, you’ll find him enjoying quality time with his wife, 4 kids, 2 dogs, 1 cat, and a cup of coffee.

Hello everyone! Every month we share some top stories from the previous month, and here’s our round-up for September.

Open-source, cross-platform MSBuild: Continuing the open-source, cross-platform .NET story that is already well underway with .NET Core and the .NET Compiler Platform (“Roslyn”), MSBuild is joining the fun as explained by Nikolai Tillmann. The sources are now on GitHub, and open to contributions as MSBuild makes its way to .NET Core.

Cross-platform apps: Choices like Apache Cordova, Xamarin, and Unity all have great support in Visual Studio. In Building your first end-to-end Cross Platform app – Part 4 – iOS App, Shashank Bisen continues his journey with Xamarin that’s already covered Windows and Android. On Channel9, Episode 9 of the Office Dev Show features Richard diZerega who demonstrates how to build a Cordova app that integrates with Office365. And Alex Lian on Unity’s blog shares news about Unity 5.2 – your gateway to Unity Services (such as Unity Ads, Unity Cloud Build, Unity Analytics, and Unity Multiplayer), and how Unity 5.2 supports the Windows 10 Universal Windows Platform a much tighter integration with Visual Studio. And check out What's new for .NET and UWP in Win10 Tools 1.1 by Richard Lander.

Microsoft Loves Linux: People have been asking “What is Microsoft doing with Linux?” and the answer, as Michael Kelley puts it in Deep Dive #1: Introduction to Linux and FreeBSD on Hyper-V is “a lot!” In addition to the work Michael describes for the datacenter, and the Linux support on Azure, Mickey MacDonald has written about how you can hook up Visual Studio Code for Linux with Unity’s experimental Linux build. And speaking of Visual Studio Code, Sean McBreen has shared that its documentation is now on GitHub.

Microsoft Loves Linux

Docker and Containers: When you bring up Linux with developers, you’ll probably get into a conversation about Docker and containers. If you want to get caught up on the subject, this Visual Studio Toolbox episode with Robert Green and Steve Lasker covers all the basics and how you can take advantage of containers from Visual Studio on Windows and Linux.

A Summer of ASP.NET: With four releases of ASP.NET in the past few months, Jeffrey Fritz brings us up to date on all the .NET web developments of late, including ASP.NET 4.6, the continued betas of ASP.NET 5, and the exciting new WebHooks extension. There’s a full series of WebHooks posts on the .NET Web Development blog from Henrik Nielsen, starting with his Introduction and continuing with detailed posts about integrating with the likes of Slack, Salesforce, and Instagram. And if you’re ready to dive into ASP.NET 5, get started with Scott Hanselman’s introduction video on Microsoft Virtual Academy.

Something old, something new: Lastly, we have a small study in contrasts. For the old, Jim Springfield shares the story of Rejuvenating the Microsoft C/C++ Compiler, noting how there are still comments in the source code from 1982. I particularly enjoyed this article because I first encountered that compiler myself only a few years later. As for the new, which in fact also relates to something very old, spend a few minutes with Introducing U-SQL – A Language that makes Big Data Processing Easy by Michael Rys, right here on the Visual Studio blog. Michael explains that when you start working with Big Data, existing SQL-based languages fall short where extensibility is concerned, and procedural languages fall short in matters like scaling. Hence, U-SQL, which brings together the best of both.

To see what else we’ve shared recently, check out top news from August 2015 and top news from July 2015, along with recent posts on the Visual Studio Blog.

Enjoy!

clip_image010

Kraig Brockschmidt, Senior Content Developer, Visual Studio

@kraigbro

In my last blog post, I introduced U-SQL as the new Big Data query language for the Azure Data Lake that unifies the benefits of SQL with the expressive power of your own code. Today we are announcing the availability of the Azure Data Lake in public preview. You can now try U-SQL in Visual Studio and run it over massive amounts of data in the store and across relational store such as Azure SQL Database. In this blog post, I will dive a bit deeper into how you can extend U-SQL queries with custom code.

One of the major values of U-SQL is how easy it is to add user-specific code written in C#. Because U-SQL’s type system is based on C# and the U-SQL scalar expression language on the instances of these types is the C# expression language, it is very easy to use the power of the C# language and the .NET Framework and assemblies in U-SQL.

U-SQL’s C# integration

U-SQL’s core reliance on C# for its type system and scalar expression language provides the query writer access to the wealth of the C# and CLR libraries of classes, methods, functions, operators and types

This starts with that all C# operators except for the assignment operators (=, += etc.) are valid in U-SQL scalar expressions. In particular, all comparison operators such as ==, !=, <, >, the ternary comparison cond ? true-expression : false-expression, the null coalesce operator ?? are supported. Even lambda expressions using => can be used inside U-SQL expressions.

This very tight integration and seamless programming experience is syntactically also enabled by U-SQL being integrated with the C# Roslyn compiler. In fact, the U-SQL integration is probably the most complex application of the C# Roslyn compiler platform.

There are several ways how C# code can be used to extend U-SQL expressions:

Provide inline C# expressions in your U-SQL script: This often makes sense if a small set of C# methods need to be applied to process one of the scalar values. E.g., a string type method or a math function.
Write user-defined functions in a C# assembly and reference them in the U-SQL script: This is preferred for more complex functions, if the logic of the function requires the full power of C# beyond its expression language, such as procedural logic or recursion.
Write user-defined aggregators in a C# assembly and reference them in the U-SQL script: By providing user-defined aggregators, custom aggregation logic can be plugged into U-SQL’s processing of aggregation with a GROUP BY clause.
Write user-defined operators in a C# assembly and reference them in the U-SQL script: User-defined Operators (UDO) are U-SQL’s custom-coded rowset operators. They are written in C# and provide the ability to generate, process and consume rowsets.

For the user-defined functions, aggregators and operators, the C# assembly will have to be loaded into the U-SQL metadata catalog with CREATE ASSEMBLY (U-SQL) and then referenced in the script with REFERENCE ASSEMBLY. The Azure Data Lake Tools for Visual Studio make the registration process a breeze and even provides a so-called code behind experience where you just write the code and submit the script and the tool takes care of all the plumbing.

In today’s blog post, let’s look at the example I introduced a month ago and dive a bit deeper into the inline C# expressions and the experience of writing user-defined C# expressions and functions with U-SQL.

U-SQL inline C# expressions

Let’s quickly recall the sample: The data is twitter history of all my tweets, retweets and mentions in a CSV file that lives in a file in my Azure Data Lake Store:

Going back to our example, I now want to add additional information about the people mentioned in the tweets and extend my aggregation to return how often people in my tweet network are authoring tweets and how often they are being mentioned. In the previous post showed you a simplified version of the following U-SQL script (please read up on the philosophy and statement processing of U-SQL in the previous post):

The highlighted parts of the script above show some of the places where U-SQL expects and accepts C# expressions. As you can see, you can use the C# expressions in the EXTRACT’s and OUPUT’s USING clause, in the SELECT clause and WHERE clause, as well as in the GROUP BY clause, ORDER BY clause and EXPLODE function, although in this example we just refer to a column name in the two later cases.

An important aspect of the integration is that the C# expressions have full access to the scalar values inside the query expression in a seamless way due to the fact that they are typed with C# types.

The EXTRACT’s and OUPUT’s USING clauses in line 6 and 32 take C# expressions resulting in a user-defined operator instance. The two built-in expressions above are calls to factory methods that return an extractor and outputter instance respectively. We will discuss user-defined operators in a future blog post in more details.

Let’s look at the C# expression from line 8 in a bit more details:

new SQL.ARRAY<string>(tweet.Split(' ').Where(x => x.StartsWith("@")))

This is a great example of the use of C#: The U-SQL built-in type SQL.ARRAY<T> is actually a C# object type that provides the expected SQL/Hive capabilities without the side-effect update functions of the existing C# Array type. You just use the C#’s new operator to create a new instance. The instance gets created by simply applying one of the many string operations on the column tweet that has been defined with the string type to break it into words. No more wondering where you get a certain string-type functionality as in normal SQL dialects: you have the full power of the CLR at your fingertips!

It gets even better. The Split method returns an IEnumerable<string>. So any further processing, such as filtering only the mentions from the tweet words can be done with a LINQ expression and using a lambda expression as the predicate. Now try that with your standard SQL language!

Let’s also look at the WHERE clause in line 21. Again, I can simply provide the C# expression referring to the columns in the rowset. The expression in this context has to result in a value of type bool. Now C# has two-valued logic and not three-valued logic as SQL. Thus the comparison r != null will return true if r is not null or false if it is null. Furthermore, by using the C# logical operator&&, I get the guarantee of C#’s execution order being preserved and more importantly, the short-cutting that will not execute the right comparison if the first will evaluate to false.

U-SQL and Visual Studio’s Code-Behind Capabilities

In the previous blog post I showed the code behind capabilities that will automatically deploy the code in the associated .cs file to the service on submission. In order to be able to refer to the methods and types and functions in U-SQL, the classes have to be defined as public and the objects need to be defined as static public.

What the tool does is actually the following steps:

The .cs file will be compiled into an assembly file.
The user’s U-SQL Script gets augmented with a header that adds a CREATE ASSEMBLY statement that will create the assembly files binary content in your U-SQL metadata catalog.
It also adds a cleanup at the end of the script that will remove the registered assembly with a DROP ASSEMBLY statement.

The following shows the modified script that the tool submits with the code behind header:

U-SQL Assemblies

I can also deploy and register the code as an assembly in my U-SQL metadata catalog myself explicitly. This allows me and other people to use the code in future scripts. It is also the preferred way to manage your user-defined functions, aggregators and operators, if you have more complex code that you want to maintain separately, where you may want to include existing code that may have been written in other contexts (like your XML or JSON libraries) or even call out to external executables (again a topic for a later blog post).

Since I have shown the code of how to use the assembly in the previous post, let me talk a bit more about the assembly management in U-SQL.

Similar to relational databases like SQL Server, U-SQL provides a metadata catalog and supports the standard database objects. One of the objects, is an assembly metadata object. By using the CREATE ASSEMBLY statement, you can register an assembly in the database. Assemblies are objects scoped to a database and the assembly DLL file gets placed into the assembly folder inside the relevant database folder inside the catalog folder in your primary Azure Data Lake Storage account.

In addition to storing your assembly, you can specify additional files that will be stored together with your assembly and will be included when you reference the assemblies. The CREATE ASSEMBLY statement syntax grammar looks like this (see the U-SQL language reference documentation for more details):

Create_Assembly_Statement :=
'CREATE' 'ASSEMBLY' ['IF' 'NOT' 'EXISTS'] Assembly_Name
'FROM' Assembly_Source
['WITH' 'ADDITIONAL_FILES' '='
'(' Assembly_Additional_File_List ')'].
Assembly_Name := Quoted_or_Unquoted_Identifier.
Assembly_Source :=
Static_String_Expression | lexical_binary_value.

Speaking of referencing an assembly, U-SQL has a small set of pre-loaded System assemblies and namespaces, including System and System.Linq. The set is kept small to keep the compilation time and the job’s resource utilization lower. If you want to refer to a different system assembly, you can just include them with the following statement that adds System.Xml:

REFERENCE SYSTEM ASSEMBLY [System.Xml];

What’s next?

The public preview of the Azure Data Lake has been opened today. So pleasesign up for joining the Azure Data Lake Analytics Preview, and give us your feedback!

In a future blog post I will dive deeper into user-defined operators. Please let me know in the comments or via the feedback link above, what other U-SQL topics you want to learn about, such as file sets, the metadata objects, federated queries etc.

Also, head over to our Azure Data Lake documentation center to read more and watch our Channel 9 video series on the Azure Data Lake.

Michael Rys (@MikeDoesBigData), Principal Program Manager, Microsoft Big Data

Michael has been doing data processing and query languages since the 1980s. Among other things he has been representing Microsoft on the XQuery and SQL design committees and has taken SQL Server beyond relational with XML, Geospatial and Semantic Search. Currently he is working on Big Data query languages such as SCOPE and U-SQL when he is not enjoying time with his family under water or at autocross.

Today we released Visual Studio 2015 Update 1 RC, which builds on the Update 1 CTP we released three weeks ago. In addition to the features introduced in the CTP as described here, the Release Candidate includes the following:

Go To Implementation. The feature many of you have been waiting for: just right-click on an interface or abstract method and select this command to navigate to the implementation.

New Quick Action. Ctrl + . now converts get methods to properties.
Windows Presentation Foundation. We’ve improved performance and added DirectX extensions (via NuGet), spell checking improvements, and additional support for per-user custom dictionaries. You can find more details on the blog post, WPF in .NET 4.6.1.
CPU Profiling while Debugging. This capability enables a per-function breakdown of CPU usage between breakpoints and in steps while using the debugger. For details, see the post Profiling your CPU in the Debugger.
C/C++ Debugging Improvements. The debugger now tells you which variable caused an access violation during C/C++ debugging. Read the blog post Improvement to Debugging C++ Access Violations in VS2015 Update 1 for more details.
Tools for Universal Windows Apps v1.2. We have made updates for.NET Native, the XAML designer, the manifest designer, Windows Store packaging, and the debugger. You can use these tools today to build apps and submit them to the Windows Store.
Visual Studio Tools for Apache Cordova. We added support for Cordova 5.3.1 and iOS 9. We've also laid the groundwork for Android 6 “Marshmallow,” and added a new plugin for Azure Active Directory authentication.
TypeScript. The latest updates include enhancements to the type system, native support for React’s JSX, completion of ECMAScript 6 support with generators and class expressions, and support for ECMAScript 7 proposals like the exponentiation operator and async functions.
Node.js Tools for Visual Studio. We added support for Node.js 4.x, support for npm 3.x, faster and clutter-free IntelliSense, faster project load times, improved stability during debugging, and code snippet support. (These tools are available a separate download: see Node.js Tools for Visual Studio.)

Improved feedback options. In addition to a simpler feedback icon in the IDE that looks good in the dark theme, we’ve redesigned the menu options to clearly separate reporting a problem and sending feedback:

For suggestions, we take you directly to UserVoice; when reporting a problem, we have a new form that specifically asks for the information we need to investigate the issue and contact you for more information if necessary:

For a complete list of features in Update 1 RC and information on bug fixes and known issues, see the Visual Studio 2015 Update 1 RC Release Notes.

Important note: the Visual Studio Emulator for Emulator and Microsoft Test Manager will not be able to acquire online licenses when used with Visual Studio Update 1 RC installed. Therefore, we recommended that you avoid installing Update 1 RC on a computer where either of those products is needed.

As always, we welcome your feedback. Share your feedback, suggestions, thoughts, and ideas on UserVoice , through the in-product feedback UI, or file a bug through the Visual Studio Connect site.

John Montgomery

John Montgomery is the Director of Program Management for Visual Studio, responsible for product design and customer success for all of Visual Studio, C++, C#, VB, JavaScript, and .NET. John has been at Microsoft for 17 years, working in developer technologies the whole time. Reach him on Twitter @JohnMont

Microsoft hosted an in-person meeting in mid-October for Apache Cordova committers and developers. The goal was to two-fold: (1) advance conversations around Apache Cordova's future road map and (2) review the project health and, where necessary, create an action plan to address any quality issues identified by developers. The themes of the meeting included our commitment to making Apache Cordova and its plugins a stable platform.

This meeting was similar to the hour-long virtual conversations that Cordova committers usually have every month, but with more time dedicated to cover all the topics. In attendance were more than 25 people including folks from Intel, Adobe, IBM, Salesforce, Monaca and Meteor. The agenda for the meeting is on cordova-discuss and the meeting minutes are also available.

clip_image002

Stability and Consistency

Developers have voiced concerns about the numerous quirks in plugins for each platform, and the group agreed to ensure that plugins perform consistently on all platforms. For example, a Cordova plugin like the camera has a long list of quirks that result in different behaviors for some of the options used when calling the API. Another example would be the file plugin where the location of saving a file depends on the platform it is used on.

We are also looking at establishing a process to triage any issues that users report on the Cordova JIRA to ensure that high priority bugs are fixed quickly.

Documentation

The group also agreed on lowering the entry barrier for using the technology by adding more documentation and organizing the existing documentation better. In addition to continuing localization of content on http://docs.cordova.io, we also have proposals for better content based on the data we have from analytics on our documentation web site. Some of the proposals include new content, organizing plugin documentation, and adding blogs about any breaking changes we add to the project.

Extensibility

Many tool-builders who build upon Cordova in their products and offering (what we call “downstream distributions”) were also present at the meeting including IBM, Intel, and Meteor. There was general agreement that Cordova should be made much more extensible so that tool developers could leverage its features even more easily. The new proposals include ways to add third party package manager and a unified logging solution that can be used by downstream distributions.

We also discussed Cordova’s usage and collaboration with new and upcoming native-hybrid technologies including ReactNative. The group has discussed areas like sharing plugins and the ability to augment existing Webviews in Cordova apps with native controls. To this end, we have been experimenting with a plugin adapter that lets developers use Cordova plugins with ReactNative plugins.

Tools for Apache Cordova (TACO)

Several committers representing larger organization shared demos of their tools leveraging Cordova. The demo of TACO was very well received and features like dev kits seemed to be an idea that we could consider adding to Cordova core. The group also acknowledged that installing the developer tools for the first time could be cumbersome, and the TACO dependency installer is a great way to get started with Cordova.

Conclusion

Overall, the project's health is very good and the committers have done an amazing job in running the project and ensuring that developers using the platform can take advantage of the latest and greatest features of each platform. The project has also been following Apache's guidelines for new releases, features and processes for running the project. The project has been steadily growing with new committers bringing new skills to the table.

Many of the news idea and features are now starting to take shape of new proposals on the cordova-discuss repository and this is a great time to contribute to the project. You can use the mailing list to join the conversations, or leave your comments on specific issues or proposals on cordova-discuss.

clip_image004

Parashuram N, @nparashuram

Parashuram is a Senior Program Manager in Visual Studio team and works on creating tools that help with cross-platform mobile development. He is also a committer and a member of the Project Management Committee of the Apache Cordova Project.