6 Comments

Snippets are the little shortcuts available in Visual Studio for all the different languages. Here's a well known C# code snippet in action:

image

It just shows up in Intellisense and when you hit TAB, it folds out into this:

image

So snippets are really useful and boosts productivity. You can even write your own very easily – it's just simple XML files. Here's a great walkthrough on how to create individual snippet files. It's a bit old, but the format is the same for Visual Studio 2012/2013.

Up until very recently, I was convinced that you couldn't ship snippets as part of a Visual Studio extension (.vsix). I've always thought it would be great if we could share useful code snippets but there wasn't really a vehicle for distributing them efficiently.

Then I stumbled upon a huge collection of awesome jQuery code snippets made specifically for Visual Studio. However, you had to manually download the snippets in a zip file and copy them to a specific location to work. I didn't like that. It would be so much better with a simple installer. So I decided to figure out how to create a Visual Studio extension for those snippets. Here's how to do it.

Creating the extension

The first thing you need is to download and install the SDK for Visual Studio 2012 or 2013. Then open Visual Studio and hit New Project… and select C# –> Extensibility –> VSIX Project:

image

That gives you an empty extension project containing only one file – source.extension.vsixmanifest. We need that file later.

First we need to create a suitable folder structure for our snippet files (.snippet) and we need to be very specific in the naming of our folders. Here's what the folder structure could look like when I have 2 C# snippets:

image

I've created a folder named Snippets and then added a folder for each language I want to provide snippets for. Inside each of the language folders you need to add yet a new folder and give it the name you want to show up in the Code Snippet Manager (example below is from the SideWaffle Template Pack).

image

Make sure to mark each .snippet file as Content to be included in the VSIX extension:

image

Adding a package file

Now we must add a new text file to the root of our project and call it whatever.pkgdef. We need this file to set some registry keys when the extension is installed. Any registry changes applied by the pkgdef file will automatically be reverted again when the extension is uninstalled.

If we only want C# snippets, then add the following lines to the pkgdef file:

// C# snippets
[$RootKey$\Languages\CodeExpansions\CSharp\Paths]
"MySnippets"="$PackageFolder$\Snippets\CSharp\MySnippets"

You can add more lines for other languages. Here's an example of a pkgdef file containing registry keys for all languages supporting snippets.

And finally, we must register the pkgdef file with our VSIX extension. We do that by opening the source.extension.vsixmanifest file and navigate to the Assets tab.  Then click the New button and fill in the dialog like this:

image

Then click OK. Also, make sure you have entered a name in the Author field in the .vsixmanifest file:

image

Testing it

You are now ready to test your extension. Simply hit F5 (or Ctrl+F5) to launch a new instance of Visual Studio – this is what's called the Experimental Instance which is used for extension building. It might take a minute the first time you open it.

When the experimental instance of Visual Studio is loaded, go to Tools –> Code Snippet Manager… and make sure MySnippets are loaded correctly:

image

That's it. You only need to do these steps once and every modification to existing snippets or addition of new snippets are automatically picked up and added to the extension.

Since I only wanted to provide C# snippets, I can delete all the other folders. My folder structure now looks like this:

image

Very simple and clean IMO.

The only thing left to do is to upload our extension to the Visual Studio Gallery. It's very simple and all we need is to build our project and locate the output file MySnippets.vsix in the bin folder.

image

The bin folder may contain a few other files, but we are only interested in the .vsix file since this is the one to upload to the Gallery. 

I hope this helps clarify thing a bit. Have fun writing snippets!

1 Comments

URL rewrites ing web.configI recently upgraded MiniBlog from using WebPages/Razor 2 to version 3. The upgrade was completely painless. I just upgraded the NuGet package and it didn't even touch my web.config. Thumbs up to the Razor team for that!

Everything seemed to work fine, but then I noticed that my root-relative links such as <a href="~/category/web-essentials"> didn't work correctly anymore. The ~/ no longer pointed to the root of my web application, but instead to the first path segment of my URL. So, when the browser was at /post/my-post, then the ~/ in my link would resolve to <a href="/post/category/web-essentials">. This was wrong.

The reason is that I use URL rewrites in my web.config to map /post/whatever to /index.cshtml?slug=whatever and that was the reason for this strange behavior. Here's my rewrite rule:

<rule name="slug" stopProcessing="true">
  <match url="^post/(.*)" ignoreCase="true"/>
  <action type="Rewrite" url="/index.cshtml?slug={R:1}"/>
< /rule>

So in order to use WebPages/Razor 3 with URL rewrites like mine, I had to tell Razor to ignore the <rewrite> segment in my web.config. That's easily done in global.asax like so:

public void Application_BeginRequest(object sender, EventArgs e)
{
     Context.Items["IIS_WasUrlRewritten"] = "false";
}

Now Razor correctly maps to the root of the website when using ~/.  

Not all cases

This little workaround is only needed if your URL rewrites happen in the path of the URL, but not if you use sub-domain rewrites. For instance, if you use URL rewrites to map sub.domain.com into domain.com/sub then it all works fine and you don't need this workaround.

8 Comments

Due to the brand new HTML editor in Visual Studio 2013, static HTML files no longer has the Design|Split|Source options enabled by default.

Design, Split and Source view

That’s because the new HTML editor is the default editor for all HTML files with the exception of ASP.NET Web Forms files (.aspx, .ascx, .master). However, it is only the Web Forms editor that has support for the designer and split view.

So all we have to do is to map our .html or .htm files to use the Web Forms editor instead of the new HTML editor.

Simply right-click any .html/.htm file in Solution Explorer and select Open With…

Open With context menu

Now select HTML (Web Forms) Editor,click Set as Defaultand then hit OK.

Visual Studio's Open With dialog

All files with the same extension will now always open in the Web Forms editor and you get both Design- and Split view.

I also recorded a short video showing a different way to accomplish the same thing.

7 Comments

Today was the long-awaited day when Visual Studio 2013 RTM was released. Check out Scott Guthrie’s blog post about all the new features for web developers. Today is also the day Web Essentials 2013 ships as version 1.0.

Don’t mix RTM and RC!

The new release of Web Essentials 2013 only works on Visual Studio 2013 RTM. Though you can install it on VS 2013 RC, some features will not surface and you might see a few alert boxes telling youSomething went wrong”.

Also, all the Browser Link extensions will only work for VS2013 RTM. That’s because the Browser Link API in Visual Studio changed slightly between RC and RTM.

You can still download the version of Web Essentials that works with Visual Studio 2013 RC.

A new web-based menu

With the introduction of Browser Link in Visual Studio 2013, it’s now possible for Web Essentials (and anyone else) to use the API to create brand new features that simply wasn’t possible before.

One such feature is the Browser Link menu that shows up at the bottom of your pages in the browsers. It looks like this:

image

It floats at the bottom of your web pages, but unless your mouse cursor is hovering it, it will be semi-transparent to get out of the way:

image

You can also toggle the visibility of the menu entirely. Just hit the CTRL key to either show or hide the menu. If you always want it to be hidden until you manually hit the CTRL key, then check the Auto-hide box on the right.

The idea behind the menu is to make it easy to discover the various Browser Link features provided by Web Essentials. Keep in mind that this is our first attempt at injecting a menu on your web pages, so I’d be really interested in any feedback you might have on this approach.

I’ve been using it for about a month now and I absolutely love having it there. I auto-hide it and then just hit CTRL when I need it and it hasn’t been annoying at all.

Stability and reliability

During the Visual Studio 2013 Preview and RC timeframe, we saw a lot of crashes caused by Web Essentials. I knew that was a possibility because the various Visual Studio API’s changed between Preview and RC (and also for RTM in the case of Browser Link).

It was therefore a top priority for me to make version 1.0 of Web Essentials as stabile and reliable as possible. A lot of bugs have been fixed and it’s probably the most reliable version of Web Essentials ever.

That said, there might still be a few hiccups left undiscovered. If you encounter any, even small ones, please don’t hesitate to open a bug on GitHub so it can be fixed.


Please enjoy Web Essentials 2013, suggest new features and send pull requests.

17 Comments

imageThis summer has been one of the most productive I’ve ever had. Normally I spend summers balancing frozen margaritas in my hammock. That’s called Hammock Driven Development. You should try it.

Visual Studio 2013 Preview was released in June at the //build/ conference. I was there giving a talk about the brand new HTML editor, Browser Link and Web Essentials. Here’s the story of my road to //build/  and Visual Studio 2013.

Starting early

Mikhail, Todd and Alex, all developers on the web editors crew, started working on a new HTML editor for Visual Studio 2013 last summer before we shipped Visual Studio 2012. The codename for this new editor was Libra. My zodiac sign happens to be Libra, so I thought it was a fantastic name.

The HTML editor was based on WebMatrix’ HTML editor, which was much newer and all written in C#. The old HTML editor in Visual Studio was a mix between C++ and C#. It was old. From the nineties actually. It also had dependencies on FrontPage. Yes, FrontPage.

We went through all aspects of the editing experience to create the best HTML editor in the world. That meant scrutinizing every little detail till we got it just right. The formatter was the most challenging piece from a UX point of view. We spent months getting it perfect. I had no idea something so seemingly simple could be such a challenge.

The formatter was just one piece of the puzzle. Another big piece was the validator. Our test engineer, Van, had for a while wanted to learn Python. So when we needed a big pile of real-world HTML documents for testing, Van decided to teach himself Python, write a web crawler and download thousands of web pages to validate against. The guy is not normal.

Libra is a huge project and we’re not done yet. We’ll never be done – the HTML editor will continue to evolve.

Visual Studio Update 1

While work continued on Libra, we were preparing for the first update to Visual Studio 2012. This update became very important, because this was the first time we introduced new modern web languages to Visual Studio. It was a great day when we shipped both CoffeeScript,LESS and KnockoutJS Intellisense in Visual Studio Update 1.

For me, this marked the day when Visual Studio entered into the modern web arena full force. Not only that, we actually shipped both CoffeeScript and LESS several months earlier in Web Essentials. The cadence of which we were able to get valuable technology in the hands of web developers was unprecedented at Microsoft it seemed.

Two other very popular features from Web Essentials was also promoted into Visual Studio Update 1 – Paste JSON as Classes and Handlebars syntax highlighting. This was a good release.

Shortly after the release, Peter was able to join the Libra effort while Mikhail moved on to another team at Microsoft. We now had all the developers on the web editors crew working full time on Libra.

Up until this time, Libra was the only project we had started working on for Visual Studio 2013. But that was about to change.

The Eureka crew

Back in October 2012 I took over as program manager for the Eureka crew. Eureka was the codename for Page Inspector, which was a feature first introduced in Visual Studio 2012. I now had the responsibility for both the web editors and Page Inspector.

I’ve always found the technology behind Page Inspector fascinating, so this was pretty exciting to me. Long before I joined the Eureka crew, I had been trying to figure out how to move Page Inspector out of Visual Studio and into the browser, but was never able to nail the right user experience. I just knew it had to live in the browser somehow.

After an evening of Ballmer Peaking with Sayed, all the pieces started to fall into place – a true eureka moment in fact. The next day I sent a mail to my boss, wherein I pitched Artery – the codename for what was to become Browser Link.The email went out February 25th, 2013.

The Eureka crew couldn’t start working on it just then. We had to finish the work on Page Inspector for Visual Studio Update 2 first. It wasn’t until April before Dan and Joe started coding on the proof of concept. At this point, we didn’t even know if it was technically possible, let alone if we were even able to make it in time for Visual Studio 2013.

We did make it, but for the June release Browser Link was very far away from being feature complete. We basically shipped the proof of concept. As you can see from this video, we’ve come a long way since then. Browser Link is going to change everything.

Side Projects

During Christmas time last year, both Sayed and I were each building a website. He built one for his new MSBuild book and I built one for Web Essentials. We gave each other tips and tricks and decided to put them all online. In January 2012 we introduced the Web Developer Checklist. It got leaked before it was done and made the front page of Hacker News on a Sunday night. We had to hurry up and finish it right then.

In June we then released the Web Developer Checklist Chrome extension, which helps web developers test their websites for best practices. Many of the items on the checklist is currently being built into Web Essentials as Browser Link extensions, so now there’s full Visual Studio integration as well. It’s funny how things progress and evolve over time. From website, to Chrome extension, to Browser Link extension.

This happened at the same time I was working on a new blog engine for ASP.NET called MiniBlog. The idea was to see how simple I could write a modern blog engine with the latest technology. Exactly the same as when I started BlogEngine.NET many years ago. I used MiniBlog as part of the demo in my //build/ talk.

Leading up to //build/, I also started porting Web Essentials from Visual Studio 2012 to 2013 Preview. It was a bigger task than I thought, but it was done in time to release at //build/. It was even used in the keynote which I was very proud of.

Now both Web Essentials 2012 and 2013 are open source and have already taken community contributions. That’s fantastic and I’m very grateful for everyone who have pitched in so far. Thanks!

In July, Sayed and I finally started working on a project we had talked about doing for months. We wanted to make it easy for anyone to create and share Visual Studio item- and project templates. The project is called SideWaffle Template Pack and is an open source community extension for Visual Studio 2012 and 2013.


Now summer is over and Visual Studio 2013 RTM is almost ready to ship. I hope you’ll have as much fun using it as we had making it.