Article
08/10/2015

September 2012

Volume 27 Number 09

Visual Studio 2012 - What's New for Web Development in Visual Studio 2012

By Clark Sell | September 2012

Do you remember the first Web site you developed? I sure do, and oh boy what a mess that was. But a great deal has changed since then—and it doesn’t stop! It’s getting harder and harder to remember what Web development was like a year ago, let alone when the Microsoft .NET Framework was first released.

Visual Studio has evolved as well. Remember when Web developers basically had to install a full server as a developer rig just to have IIS and SQL Server to run their sites? Then we were introduced to the more lightweight world of Cassini, and then IIS Express. Now HTML5 is here and Visual Studio embraces it.

I’m going to explore how Visual Studio supports this new-world Web developer, with a look at exciting new features such as project sharing, Page Inspector and DOM Explorer, as well as a look at how the core editing experience continues to evolve.

You might notice the new Visual Studio features with the first click of your mouse, when you open a project file. In the past, project files were directly dependent on the editor you used. That meant if you had a project file created with Visual Studio 2010 and you tried to open it with Visual Studio 2012, you’d be asked to upgrade it. Once you did that, you could never again open the project in the older version. Well, not anymore.

The Visual Studio 2012 release candidate (RC) introduced the notion of project sharing. Now you can use it interchangeably with Visual Studio 2010 SP1 on the same source. Eliminating the requirement that everyone must use the same setup opens the door to new experiences, especially on diverse teams and open source projects—or even during software upgrades in your development shop.

Of course, there are a few caveats. For example, if your project uses a local database (the App_Data folder), you’ll need to make sure you’re still using the same version of the database engine. There are also a few older project types, such as ASP.NET MVC 2, that won’t work with this.

As with anything new, you’ll want to create a fork and do a few proofs of concept. The last thing you want to get caught doing is breaking the build process.

HTML5 Support

Probably the most significant feature to be added to the HTML editor in Visual Studio is Web Accessibility Initiative - Accessible Rich Internet Applications (WAI-ARIA) support. WAI-ARIA (w3.org/WAI/intro/aria) is a Web standard focused on making Web sites and Web applications more accessible to people with disabilities. The specification defines two types of attributes for your markup. Roles are applied to HTML elements to describe the type of widget being used or the structure of the Web page. As you can see in Figure 1, Visual Studio support for ARIA roles includes IntelliSense.

Figure 1 ARIA Roles

The other type of attributes are prefixed with aria-, such as aria-busy or aria-valuemin, as shown in Figure 2. These aria-* attributes are used to help describe the element to a user.

Figure 2 ARIA-* Properties

HTML5 introduced more than 25 new semantic tags. Visual Studio already had IntelliSense support for these tags, but Visual Studio 2012 makes it faster and easier to write markup by adding some corresponding snippets, like the ones for the audio and video tags. Figure 3 shows a snippet for the video tag. Though these tags aren’t complicated, they come with a few small subtleties, such as adding the correct codec fallbacks.

Figure 3 A Snippet for the Video Element

The last few Web sites I built took advantage of the new HTML5 tags. With each of these sites, I ended up refactoring my markup in some way, even if it was just a simple semantic change, such as changing a div to a section. In Visual Studio 2012, when you change an element, the editor will also change its corresponding starting or ending element. This automatic renaming is another way the editor helps you avoid those late-night mistakes.

Developers often differ over whether to use tabs or spaces for formatting. No matter which you prefer, Smart Indent is here to keep you consistent. Regardless of your choice, after typing an element and hitting enter, you’re taken to the next line, which is indented as you prefer.As you’d expect, IntelliSense has added filtering not only as you type but also based on the title case of the words in your searches, making it quicker and easier to insert elements. And when combined with Smart Indent, no matter where you drop the cursor, after hitting tab your new markup will automatically be positioned correctly in the document, as Figure 4 shows.

Figure 4 Intelligent Filtering and Indenting

Finally, the Visual Studio 2012 HTML editor has a number of great additions that support ASP.NET, such as Smart Tasks, extract user control and automatic event binding. You can find out more about these features on the “What’s New in ASP.NET 4.5 and Visual Studio 2012” page at bit.ly/MXcIbG.

JavaScript Support

The JavaScript editor in Visual Studio 2012 is completely new and supports ECMAScript 5. It brings some nice features like collapsing functions and brace matching. And if you’re still scrolling around for a function, don’t. Just hit F12 and get taken directly to the definition of that function or variable (see Figure 5).

Figure 5 The JavaScript Editor

The editor also enhances IntelliSense for JavaScript development and, along with it, improved support for the Document Object Model (DOM). With HTML5 becoming mainstream, it’s great to have this enhanced support not only for the basic new DOM APIs but also when you decide to extend them, as Figure 6 shows.

Figure 6 IntelliSense for JavaScript

Documentation is always a good thing to have, especially when it’s the kind of documentation that lives in the IntelliSense window. VSDoc support is not new to Visual Studio, but it now includes a new signature element for declaring overloads of JavaScript functions that let you create detailed IntelliSense comments. Ignoring my code quality for a second, take a look at Figure 7, which shows a function that takes either two or three arguments. As you can see, the code has a series of <signatures> for each overload, with the results shown in Figure 8.

Figure 7 A JavaScript Function That Uses the Signature Element

function myAwesomeFunction(a, b, c) {
    /// <signature>
    ///   <summary>This is my awesome function</summary>
    ///   <param name="a" type="String">Clearly you should pass A in here.</param>
    ///   <param name="b" type="String">Clearly you should pass B in here.</param>
    ///   <returns type="String" />
    /// </signature>
    /// <signature>
    ///   <summary>This is my awesome function</summary>
    ///   <param name="a" type="String">Clearly you should pass A in here.</param>
    ///   <param name="b" type="String">Clearly you should pass B in here.</param>
    ///   <param name="c" type="String">Clearly you should pass C in here.</param>
    ///   <returns type="String" />
    /// </signature>
    return "yea pretty awesome";
  }

Figure 8 Comments Added to IntelliSense

With that simple documentation in place you can see in Figure 8 how IntelliSense used it for the contents displayed.

CSS3 Support

For me, CSS continues to be a mystical art, and one I can never get enough help with. Luckily, Visual Studio 2012 has enhanced support for CSS. Regions, IntelliSense and snippets are just a few features that can help improve your style. Let’s start by looking at regions. All it takes is a special comment to create a region. Figure 9 shows a simple region both expanded and collapsed for styling a table.

Figure 9 Regions

As you know, in the Web world you must support multiple browsers. With CSS, that means accounting for all of the different vendor prefixes. The Visual Studio 2012 CSS editor now includes vendor prefixes in both the standard list of properties and also in the built-in snippets, as shown in Figure 10.

Figure 10 Properties for Vendor Prefix -moz

Of course, there are many CSS properties at your disposal and filtering is essential. As with IntelliSense for C# and Visual Basic, you can filter that long list of CSS properties just by typing, as Figure 11 shows in the search for borr (border-radius).

Figure 11 CSS IntelliSense

This is great, but for border-radius you should really support all of the vendor prefixes. If you look closely at the border-radius icon, you’ll see it’s actually a snippet. Hit the tab twice, once to auto-complete the property and again to insert the snippet (see Figure 12).

Figure 12 A CSS Snippet

You can see that all of the vendor prefixes were added and the value is now highlighted for you to change. As you type the desired value for the radius, all vendor-specific values will change accordingly. But what about something more advanced, like a media query? Type @ and you’ll see a list of advanced snippets such as @media. Select @media then hit tab and the media query snippet will be inserted. Now you can just type in your new width, hit tab and adjust your height (see Figure 13).

The <span class= @media Snippet" title="The @media Snippet" />
Figure 13 The @media Snippet

Snippets are a fantastic way to save on keystrokes. Just as in C# or Visual Basic, you can create new snippets or modify existing ones through the Visual Studio Code Snippet Manager, which you’ll find at Tools | Code Snippet Manager.

Visual Studio also has a new color picker for those properties that require color; it replaces the named colors in previous versions. As you can see in Figure 14, I’ve chosen to pick a color with a bit of transparency, so the color picker changed from a standard hex color to rgba.

Figure 14 The New CSS Color Picker

Finally, be sure to check out the support for hierarchical indentation and CSS hacks at bit.ly/MXcIbG.

Debugging with Page Inspector

“Hey, it works on my machine!” I guarantee you’ve either said that phrase or heard it more than once during your career. In Web development, it’s almost guaranteed you’ll hear that phrase sooner or later, and why is that? Well, in part it’s because what we deploy to and what we develop on are not identical.

Leaving aside the obvious things like security and server farms, it really comes down to what the browser will execute and render. Over the years, technologies such as HTML5, CSS3 and JavaScript have advanced, and we use a vast array of frameworks, including some that might only ever run in the browser (such as knockout.js and backbone.js). Web developers have to deal with two different worlds: how the app is developed and how it runs across all of the different browsers that need to be supported.

Browser tools have advanced accordingly, which helps a great deal, but you still might need an archaeological dig to find the original source file. Even if you consider simple JavaScript minification and script loaders, what might be sent to the server could be drastically different from what you’ve developed. Thankfully, Page Inspector, one of my favorite additions to Visual Studio 2012, is here to help. Page Inspector brings browser diagnostics tools directly into Visual Studio. By doing so, it provides an integrated experience from the browser to ASP.NET and right to the source code. It does all of this with minimal setup.

You can run Page Inspector out of the box with limited functionality. To do so, just right-click on the page you want to view and select View in Page Inspector. Now, I know what you’re thinking: “There’s no way that will work on my MVC project or with all of my custom routes.” Have some faith.

Page Inspector will do its best to actually map the file to the URL convention used. Where it fails, you can manually add that mapping. To fully enable Page Inspector and all of its features, just add a new key to the appSettings section of your web.config:

<add key="VisualStudioDesignTime:Enabled" value="true" />

Page Inspector is all about plugging that “gap” I mentioned earlier, between what was developed and what was rendered. Wouldn’t it be nice if you could just highlight something in the rendered output and find what file it’s in—or, better yet, change it? I know you can do that already in the browser tools, but I mean for good, actually in the source it came from. With Page Inspector you can do this, as it maps between the rendered output and the source files it came from. When you start Page Inspector, you’re basically presented with a browser window inside Visual Studio, as shown in Figure 15.

Figure 15 Page Inspector

There’s a lot going on here, but let’s break it down:

The chrome of the window is a browser frame. You can see the address bar at the top.
The top half of the page is the actual Web page as rendered to the browser.
The bottom left is the HTML markup for the rendered page. This is because HTML was selected in the tab directly above.
The bottom right is the style for the rendered page.

Similar to the tools found in the browser, there’s a feature called Inspect. When you select Inspect, as you move around the page you’ll see the different DOM elements highlighted and labeled. In Figure 15, the element is hgroup with a class called title. You’ll also see in the HTML window the corresponding markup highlighted. This happens in real time as you move around the document. As if that weren’t cool enough, take a look at Figure 16. I’ve selected or hovered over an element in Page Inspector and behind it you can see it’s highlighted in the correct source file where that text resides. This doesn’t just happen at the element level but all the way down to character. It’s a live character-by-character, two-way mapping from the source to the rendered output. Regardless of what you select (source or rendered output), you’ll see it highlighted.

Figure 16 Mapping Between Source and Rendered Output

I’ve just scratched the surface of the capabilities of Page Inspector. This is one of those features that you need to use to fully appreciate how it can make your life easier. Prepare to be amazed. Next time you’re in a Web project, right-click on a page and select View in Page Inspector.

Publishing

What good is a Web site if you can’t deploy it? Visual Studio has long had support for deploying sites, including a feature called Publish Profile. Historically, once a profile was created it was only a local machine asset. In Visual Studio 2012, this profile is now part of the overall project assets. It’s a simple MSBuild file, which will get imported into your overall MSBuild chain. Here’s what a simple FTP profile might look like:

<Project ToolsVersion="4.0"
  xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <WebPublishMethod>FTP</WebPublishMethod>
    <SiteUrlToLaunchAfterPublish>https://thatconference.com
      </SiteUrlToLaunchAfterPublish>
    <publishUrl>ftp://thatConference.com</publishUrl>
    <DeleteExistingFiles>True</DeleteExistingFiles>
    <FtpPassiveMode>True</FtpPassiveMode>
    <UserName>foooooo</UserName>
    <_SavePWD>True</_SavePWD>
  </PropertyGroup>
</Project>

You can find these profiles saved in the overall project properties folders:

C#—Properties\PublishProfiles
Visual Basic—MyProject\PublishProfiles

Because it’s an MSBuild project file, of course you can call it from the command line, like so:

msbuild.exe myProject.csproj /t:WebPublish /p:PublishProfile=ProfileName

HTML5 on Windows 8

At last year’s BUILD conference, Microsoft announced a new programming model for building native apps on Windows 8. As it turned out, this new programming model isn’t really new at all; part of the development story is simply a new reliance on HTML5, CSS3 and JavaScript to build applications. This means anyone with a Web development background has a skill set applicable for writing native apps for Windows 8. Of course, Visual Studio is right there to help.

A number of the core editing improvements I’ve discussed here are still applicable for developing Windows Store apps, with the exception of Page Inspector (because Windows Store apps don’t run in a browser). How, then, do you debug HTML5 Windows Store applications? With the DOM Explorer and the JavaScript Console, as shown in Figure 17.

Figure 17 The DOM Explorer

As with Page Inspector, you can select elements from the running application and go directly to the location in the source. You can see the styles applied and change values while the application is running. Want to put a breakpoint in some JavaScript? Go ahead, and then do some live debugging. You can even fire up the JavaScript Console and start hacking around. Regardless of whether you’re building a Web site or an application for Windows 8, it’s the same, with the same features across both platforms in one great editor.

If you’re reading this, chances are pretty good that you use Visual Studio. I’ve used it myself for more than a decade and I’ve learned with every major release that it’s good to remind yourself to explore all of the new features. It’s too easy sometimes to just stick with what you already know, so go and poke around. It’s great to see Visual Studio embrace current technologies like HTML5, CSS3 and ECMAScript 5, while putting facilities in place for upgrading as standards change.

Clark Sell works as a senior Web and Windows 8 evangelist for Microsoft outside of Chicago. He blogs at csell.net, podcasts at DeveloperSmackdown.com and can be found on Twitter at twitter.com/csell5.

Thanks to the following technical experts for reviewing this article: Matt Carter and Orville McDonald