| Comments

A few weeks ago I had the great pleasure of being in front of you, our developer customers (and friends) at the Microsoft BUILD conference. (I never know how to write “build” in a sentence and refuse to use the “//” in front of it.) These are things that I LOVE doing and wish I could do it more. I had the privilege of introducing an overview of what was new in the XAML UI framework for Windows 8.1. All the sessions are recorded so please go view mine and review it how you think so they might invite me back!

In my session I gave some preview of some of the great new XAML tooling that is introduced for developer productivity in Visual Studio 2013 which, as of this writing, is currently in preview form and available for download. My colleague Unni followed my session with one specifically about XAML tooling enhancements with a whirlwind tour of all the new features. Please go check out his session: What’s New in Blend and Visual Studio for XAML Developers for the complete details.

One of the things I showed was the introduction of Visual Studio (VS) code snippets for the XAML editor. This was one of the customer requests for a while for the XAML editor and is now available in the VS 2013 preview! In my presentation I showed a common task that I do which is to have many elements and wrap them in a StackPanel. I’ve gotten lazy and wanted a quick ‘refactor’ way to do this and now I can! A few have emailed me asking where the snippet I used was as nothing was working in the preview for them. As of this writing, the functionality was in the preview, however no default XAML code snippets are provided. I’ve responded to a few on an MSDN forum thread offering to share my snippets and someone suggested I post more details, so here it is!

Anatomy of a Code Snippet

Code Snippets in VS are basically XML files that sit in a special location (one of two locations, global or user). These code snippets can apply to many things including languages (C#, VB, etc.) as well as ‘markup’ languages (CSS and now XAML). You can read more in-depth data about VS Code Snippets here. The basics that I think you want to know are the two main types of snippets: Expansion and SurroundWith.

An Expansion snippet is one that you invoke and it gives you placeholders for stuff to fill out. My most widely used one is ‘foreach’ in C#. You start typing foreach, then hit tab-tab and you are presented with a template, more or less, to complete. A SurroundWith snippet is one that surrounds (duh!) the selected content in the editor surface with your template. An example of this is the #region snippet which puts the begin/end region tags around selected code. It is important to note that these can be used exclusively or together. That is to say I can have a SurroundWith snippet that is also an Expansion. In fact, the #region one is a good example: it surrounds the selected code and also gives you a field to complete for the region name. The Code Snippet structure is the same for most languages with the difference being that in the Code node of the snippet definition it defines which language it applies to for the editors.

NOTE: Creating Code Snippets is a very manual process. At the time of this writing there was no really great tool to “extract” a chunk of code and turn it into a code snippet. There are a few attempts out there, but most have been abandoned and not all working.

Once you have these XML files (.snippet files for VS), you place them in well-known locations or can use the Code Snippets manager in VS (more on that later).

XAML Code Snippets

As noted above the XAML code snippets are the same structure as the C# snippets with the difference being the Language attribute on the Code node in the definition. In my demo I used a StackPanel SurroundWith snippet with the following definition:

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippet Format="1.0.0" xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
    <Title>Vertical StackPanel</Title>
    <Author>Tim Heuer</Author>
    <Description>XAML snippet for surrounding content in a vertical StackPanel</Description>
    <Code Language="XAML"><![CDATA[<StackPanel>$selected$$end$</StackPanel>]]></Code>

Notice the <Code> element and how it has the Language=”XAML”? That is the only difference between this and a C# one. There are keywords for certain things like selected (which is a marker for selected content) and end (which is where you want the cursor to be at the completion of the snippet) that you can use and are in the documentation. Here is another example of an Expansion XAML snippet for an AppBarButton:

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
    <CodeSnippet Format="1.0.0">
            <Description>Code snippet for XAML AppBarButton</Description>
            <Author>Tim Heuer</Author>
                    <ToolTip>The Icon value to use for the visual</ToolTip>
                    <ToolTip>The text label for the button</ToolTip>
                    <Default>My Label</Default>
                    <ToolTip>The unique ID for the button</ToolTip>
            <Code Language="XAML"><![CDATA[<AppBarButton x:Uid="$uniqueid$" x:Name="$uniqueid$" Label="$label$" Icon="$icon$" />$end$]]>

As you can see they are pretty simple to use!

Adding Code Snippets to VS

There are two ways to distribute snippets: as raw .snippet files or with an installer. You can send someone a .snippet file and they can use the Code Snippets Manager tool to import it into their environment. This is a per-user method. From VS you would use the Tools menu and choose the Code Snippets manager:


From here you would navigate to the XAML folder, then choose Import and select your .snippet files. These would then import them into your local profile (Documents\Visual Studio 2013\Code Snippets) and be ready for immediate use. Another way is through an installer. Now up until VS 2013 there was the VSI installer (as documented here on MSDN) which has since been eclipsed by the VSIX extensibility method. Right now there doesn’t appear to be much documentation on this method, but you *can* distribute code snippets via the VSIX installer. VSIX is basically a ZIP file format with a manifest and content. For this purpose the manifest describes the targets and the package definition for the VSPackage we are installing, which is in this case a folder of snippets. This is a little tricky method to get VSIX to use as an installer for snippets, but works. I won’t detail out the entire process here, but leave you with a few screenshots and you can download the file and look at the contents to see how it works…again it is a regular ZIP file so just rename and explore.

Contents of VSIX:

Contents of VSIX package

Installer dialog:

VSIX installer dialog

Once installed your VSIX-deployed snippets show up in the Extension Manager:

Extension manager listing

And there you have it! A simple way to distribute your code snippets. This VSIX can be put on VS gallery as well so that you can update it there and anyone who installed it can get updates from within VS itself!

To actually use the code snippets, from within the XAML editor use the shortcuts CTRL+K,S (for surround snippets):

Surround code snippet

or CTRL+K,X (for expansion snippets):

Expansion snippet

Expansion snippet completed


Code snippets can be a powerful productivity tool for VS. You probably use them daily (like foreach) and maybe didn’t even realize it! Now that this concept is extended to XAML there are some great opportunities to increase your markup productivity by encapsulating some things that you do often into a XAML code snippet. Right now the VS gallery doesn’t support uploading the method for VSIX that I have described so you can download my VSIX for some code snippets examples here for now.

Hope this helps!

| Comments

This week was TechEd North America, a conference from Microsoft for technical professionals covering the span of pretty much everything Microsoft produces to support IT professionals and software developers.  I was pleased to have been invited to speak on developing Metro style apps in XAML for .NET developers.  Like most developer presenters, I planned on showing a lot of demos, using different tools, editors, and varying code samples, URLs, etc.  When you are a presenter at a conference you usually don’t have the luxury of sitting in your office and doing things without distractions.  You want to get across your message of your presentation and also be able to have some good demonstrations articulating your points.  When you have a lot of demos, most of the time presenters will rely on some form of snippets – something for them to either type in quickly, copy/paste, or drag/drop onto editors.

I’ve used various snippet concepts over the years:

  • Using the Visual Studio Toolbox area and dragging text there (yes, did you know you can do that)
  • VS Code Snippets
  • Custom WPF “always on top” snippet utility (developed by a WPF team member when she was doing presentations)
  • Other 3rd party macro tools

But mostly I, like others, have relied on good ol’ notepad.  For each presentation I have a file and just blocks of code separated with headers denoting to me which step the snippet is for in the demonstration.  I don’t always use snippets because I do have some sense of pride in being able to demonstrate yes, I do actually know what I’m talking about and not just always copy/pasting!  However, again, for efficiency and to get many points across, it is an effective way to start from a blank slate (project) and build up how code gets structured for your particular concept.

Notepad has been great and reliable so I’ve always used it.  The other methods are more laborious to set up and sometimes error prone…aside from the fact they don’t work in all scenarios (i.e., VS code snippets don’t work in XAML…argh). 

This week while preparing in the speaker room with my colleague John Lam (who also gave a presentation on the Windows Runtime) he was using a new utility I hadn’t heard of before.  I usually get my little widgets of knowledge from Scott Hanselman’s massive list of tools.  Most I don’t use, but there are some really helpful gems in there.  So I was surprised about this new tool John was showing me I hadn’t heard of before.

YES, I realize this is probably not a new tool and this invites comments of ‘duh, this has been around forever dude’ so feel free to not post those.  It is new to me, like in that new used car kind of way.

When John was walking through his demo he was typing what seemed like random keystrokes in various places: VS, Blend, Notepad, dialogs, command prompt, web apps.  All of these were translating into blocks of text, shell commands, etc.  He lit up showing me about this new tool, AutoHotkey.

AutoHotkey is a very small tool that basically is a mini macro language.  I’m going to completely under-sell it for it’s likely true abilities, but even for the simplest use it has been a new favorite.  AutoHotkey works by listening to the accessibility features in Windows (also referred to UIA) for anything that has input focus.  Yes, that’s right, anything.  You define a ‘macro’ keyword and then what the command defines.  For me, this was just needing to be a series of copy/paste automation.  Here’s an example of one of my snippets:

   1: ; clear clipboard
   2: ^+x::
   3: clipboard = ; null
   4: return
   6: ; Initial StackPanel stubs
   7: ::d1::
   8: clipboard = 
   9: (
  10: <StackPanel>
  11:             <TextBlock FontSize="53" x:Name="FirstName" />
  12:             <Button Content="Click Me" Click="Button_Click_1" />
  13:         </StackPanel>
  14: )
  15: send ^v
  16: return

Anything preceded with a semicolon is a comment.  The next line is the macro command it will listen for when input has focus.  In the above there are two “^+x” means CTRL+SHIFT+X.  The command is followed by two colons which is the delimiter for the command.  The simpler one for “d1” shows how you issue a copy/paste.  I tell it what I want to put on the clipboard, then say to send a CTRL+V (paste) and end the script with a ‘return’ statement.

The beauty is that there is no “app” that you have to run – your script is basically the app.  You create your script in a text file named with an .ahk extension.  When your script is complete, double-click on it and it is now listening.  You’ll get an icon in the system tray showing you that it is running and some options (i.e., you can pause it, edit, reload to tweak):

AutoHotkey example

What is cool is that if you want to see how it is working and what it is doing you can look at the “spy” feature:

AutoHotkey spy

to see how it is listening to automation events and input focus. 

The other great feature it has is that you can compile your script.  What this does is take your script (ahk file) and compiles the AutoHotkey runtime into it as well, producing an EXE.  Now you can take that EXE to any machine and double-click and boom, your snippets are available and listening.  So now I can can compile my snippets for each presentation and put them alongside my other presentation materials on my SkyDrive…keeping everything together and quickly restorable to any machine.  Awesome.

I immediately started using it and became an instant evangelist to other presenters that moment.  John Papa used it in his presentation as well and Pete Brown I think is now converted as well.  For me it worked great, no issues. 

Creating the script was a bit of trial and error because the documentation is, well, not great.  It does SO MUCH MORE than what I’m using it for which is why I felt the docs lacking for the simple cases.  The ‘return’ keyword was critical for me to get mine working without error.  When you install AutoHotkey there is also an “Extras” folder that contains plugins for various editors: VIM, Emacs, TextPad, SciTE, Notepad++ and more.  These allow you to get syntax highlighting in these editors quickly.

Thanks to John Lam for turning me on to this. UPDATE: I’m the idiot because it *is* on Scott’s list.  My search wasn’t good enough apparently :-) and maybe Scott Hanselman will consider it for his ultimate tools list this year.  What is also awesome is that there is a Chocolatey installer for it so I just added this to my personal just-repaved-my-machine-please-give-me-my-utilities package.  Be sure to check it out if you find yourself doing a lot of snippets.

Hope this helps!

| Comments

If you are starting to get into integrating web services with Silverlight, you'll notice that you have to have a cross domain policy file in place on the target server, that is to say, the server hosting the service you want to implement.  There are some public web services (Flickr, YouTube, Digg, etc.) that already have these files in place for Flash, but implement in a slightly different way.

When calling a cross-domain service, Silverlight will check for the existence of clientaccesspolicy.xml first.  This is the format defined by Silverlight and provides a pretty flexible way to define who can access what services.  If not found, it will then default to look for crossdomain.xml, which is the file format implemented for Adobe Flash.  It is important to note that this file will also still work for most public web services.

But now perhaps you are the author of the service that your application is going to consume and/or the public will consume.  There are a few things you want to consider.  First, it would be a best practice to put your service layer on a separate domain other than your site (i.e., api.mysite.com).  In fact, this is how most are doing it these days.  These helps separate more distinctly the services from the web site and also separates the cross-domain security concerns away from the content site versus API access.  Once you have done that you'll want to implement your specific clientaccesspolicy.xml file.

When Silverlight 2 was released to beta, I created some quick helper files to assist me with creating this simple policy file (it is simple, but can get complex depending on how granular you want to define your access).  I figured it might be helpful to some who are implementing services as well.  Sure, they aren't going to save the world, but might save you some quick typing.

Visual Studio Code Snippet

The slcap.vsi file is a Visual Studio Community Installer package which contains "slcap.snippet," which is a Visual Studio code snippet format.  This is an XML snippet, so would be used only in the context of an XML file.  Just double-click on the .vsi file to install and it will walk you through the steps.  I recommend just keeping the defaults.  After it is complete, you now have an Intellisense snippet.  To use it and create a new clientaccesspolicy.xml add a new XML file to your web service site/project named clientaccesspolicy.xml.  It will open a blank XML file by default.  Select all text (CTRL+A).  Then hit the keyboard shortcut for launching XML snippets, CTRL+K,X.

NOTE: For some reason XML snippets don't operate like C#/VB ones do where you type the shortcut, then TAB, TAB.  If anyone knows why, let me know :-)

This will bring up the navigator, then simply navigate to the My XML Snippets, then locate the one you just installed:

Once you select it, there are three literal areas to override the defaults if you wanted. 

UPDATE: As Sean probably ran into below (in comments), the above screenshot does not show the required http-request-headers attribute required on the allow-from node of the policy file.  This is, however, updated in the Intellisense files and the code snippet template.  Thanks Sean for pointing out the screenshot is wrong here.

If you are implementing a completely public web service (open to anyone for cross-domain access), then the defaults will suffice.  When done changing the values, hit enter and you are done.  For those who are not keyboard shortcut masters and would be using a mouse to do all this, it might not be terribly faster to be honest (if the TAB,TAB implementation was there for XML snippets, it would eliminate the arrow up/down to navigate to the snippet).

Get the slcap.snippet here.

Visual Studio Intellisense Files

This next step is a super hack that I originally did and decided it might not be a good idea, but I'll include it here anyway :-).  This involves adding Intellisense files to your VS2008 installation and if you aren't comfortable with that, then move along.

First, you'll want to get the XSD I created, which is very simple and I'm sure doesn't fully conform to the final spec, but lacking that spec, it maps to the format well enough.  Copy the clientaccess.xsd file to the C:\Program Files\Microsoft Visual Studio 9.0\Xml\Schemas location (or wherever VS2008 is installed for you).  Once you've done that you have to add an entry into the catalog.xml file to add the mapping.  Again, not this is my little hack so I created some namespace because there wasn't one defined yet.

Once you have those two files you have Intellisense for your clientaccesspolicy.xml file if you want it.  Following similar steps as above, create the new file.  This time, however, type the root node of <access-policy> but adding the 'xmlns' attribute pointing to the new namespace you just added to the catalog file (note: Intellisense should give you a list to choose from:

Once you have that, then you'll get the rest of the Intellisense for the basic format of the client access policy format.  If you have multiple allow-from/grant-to needs, this Intellisense will support it.

The only lame thing is you have my namespace in there :-).  That is what drives the Intellisense.  Right now you'll want to remove that before deploying the actual file.  Yeah, I know.  But I said this was an early hack of mine didn't I?

Get the Intellisense files here.

What do to with the completed policy file?

Either way, when you are done with the file, it needs to go in the ROOT of the domain.  This is important as it is not the application root, but the root web.  Even if your app is at foo.com/myapp, the policy file needs to be at foo.com/clientaccesspolicy.xml.

Anyhow, maybe these files will help you.  Ideally you won't be using/messing with an access policy file much, but this might save you some clicks and having the docs open next to you :-).