Category Archives: Pro-Dev

Fabric Explorer Updated

To coincide with the publication of my new Pluralsight course on Office UI Fabric, I’ve updated the Fabric Explorer Chrome extension I published a while back to version 1.3.  This is a minor update, but it fixes a few bugs:

  1. Added support for pages loaded into the browser via a file:// URL
  2. Fixed bugs that prevented the “Reset” button from correctly returning an element back to it’s original state when the page was loaded

In addition, I added the remainder of the Fabric Responsive Grid classes (hidden, offset, push, pull), did some minor code cleanup and published the source code to GitHub.

The update was published on the Chrome Web Store this morning and should be automatically updated if you already have it installed.  If you haven’t installed it already, now is the perfect time to do so!  You’ll get the latest and greatest bits right away.

Please log any bugs here:

The extension is available here: 

Office Fabric UI Snippets for VS Code

Update for Release 1.2:

Update for Release 1.0:

Release Date: Feb 26, 2016

Status: Beta

Provided By: Sector 43 Software (David Mann)



Based on: Fabric release 2.01 (Feb 5, 2016)

These snippets are a first go at making the Office UI Fabric easier to use. In general, the HTML is taken directly from the Office UI Fabric GitHub repository, with some tweaking.

Snippets generally fall into one of two flavors:

  • Simple Components: these have no JavaScript elements and so the snippet just expands into the correct HTML to render the component
  • Complex Components: these aren’t really “complex” they simply have some JavaScript associated with them. In these cases, there is a snippet for the component and one for an example of the JavaScript required to make the component work.

All of the snippets have a trigger that starts with uif- so you can see what’s available by simply typing uif- and looking at the Intellisense popup shown by VS Code.

Installation Instructions

For the time being, installation is manual. Once I’ve ironed out any bugs, I’ll make a true VS Code extension and deploy it to the Extension Gallery. At that point, I’ll also create a Visual Studio Extension and deploy that to the Visual Studio Gallery as well. If there is interest, I’ll convert the snippets to other editors – Sublime is one I’m considering, but am open to other suggestions as well.

To Install:

  • Open the file VSCodeFabricSnippets.txt from the GitHub repo (direct link:
  • Select all of the contents and copy it to the clipboard
  • In VS Code, click File | Preferences | User Snippets and select HTML from the Language dropdown
  • Paste the contents from the GitHub file into the html.json file that is now open in VS Code
  • Save the html.json file and close it

The snippets are now available when you are editing an HTML file in VS Code. (NOTE: Snippets in VS Code only seem to work if the HTML file is open as part of a folder, not if you just open a standalone file. I’m looking into whether this is really true, and if so whether it is by design or a bug)

Installation and usage is shown in the short video here:

Known Issues

The following components are not currently supported by the snippets:

  • Facepile
  • People Picker
  • Persona
  • Persona Card

They’ll be coming in the next release.

Please report other issues here:

Getting Started with Visual Studio Code

Blah, blah, blah…intro to VS Code and why you should use it…blah, blah, blah.

If you’re here, I’ll assume you know what VSC is and are at least planning on kicking the tires to see what it’s all about.  This article is as much for me as you – a place where I document all of the little steps I needed to go through to get things set up the way I wanted.  Here’s basically what we cover:

  1. Configure Git, including credential caching for GitHib
  2. Configuring Karma
  3. Configuring TypeScript support

Let’s get started…

Configure Git, including credential caching for GitHib

VSC has support for Git built in:


Click there to go to the Git Panel.  The first time you visit, it will look like this:


Click the blue “Initialize git repository” button to, well, initialize your git repo.  Enter a Commit message and click the checkbox.  Your files are now committed to the local repo.  So how do we push them to a remote (GitHub) repo?


  1. From a command prompt, and assuming you have Git tools installed that provide command line support, enter the following two commands:
    git remote add origin your_remote_git_repo_urlgit push -u origin master
  2. Depending on how your remote repo is initially configured, you may get an error here saying that basically the remote repo isn’t empty.  You can overcome that by doing a “pull” first or a “sync”
  3. You’ll be prompted for your credentials – enter them for now, we’ll get them cached next.  When the second command is done, you should be able to see your commit in your remote GitHub repo
  4. You can now also use the menu options  in VSC to interact with your GitHub repo:


Caching GitHub Credentials

I had Git Desktop installed already and I’m not sure if that is required for this or not.  Try it without but then if it doesn’t work, try it with.

From a command prompt (again, assuming Git tools installed and in PATH), run the following command:

git config --global credential.helper wincred

Your credentials should be cached and you should no longer be prompted by VSC again every time you connect to GitHub.

Configuring Karma

Nothing really special to configure Karma for VSC.  When I’m coding, I typically just run

start Karma

from a command prompt in my project folder (assuming that’s where my karma.conf.js file is located) and let it run in the background. Eventually I’ll get around to automating the start and stop of Karma with gulp, but this is good enough for now.  I configure Karma to watch my files so it fires every time I save.

Configuring TypeScript support

You can skip this step if you don’t use TypeScript.  I do, so:

  1. Use the instructions in the following two links to configure things:
  2. For reference, my tsConfig.json file looks like this:
      "compilerOptions": {
         "module": "amd",
         "noImplicitAny": false,         
         "removeComments": true,
         "preserveConstEnums": true,
         "declaration": true,
         "sourceMap": true,
         "target": "ES5",
  3. The top of my tasks.json files looks like this:
    	"version": "0.1.0",
    	"command": "tsc",
    	"isShellCommand": true,
    	"showOutput": "always",
    	"args": [
    		//add your .ts files here		
    	"problemMatcher": "$tsc"

    Nothing below that was changed from the default

That’s about it.  I’ll probably flesh this out later, but for now this is my notes for what I needed.  Hopefully that helps someone. 

All Developers Can Be SharePoint Developers

That’s the title for a full-day session I’m doing at the upcoming Philly Code Camp (October 10, 2015, Philly MTC in Malvern – more information).  Registration is only $76 and includes breakfast and lunch, raffles, guaranteed admission to the Saturday regular Code Camp (which will sell out), and more.  Register here.

Here’s the synopsis for the day:

Until recently, SharePoint was the red-headed stepchild of the Microsoft web development world, requiring intimate knowledge of SharePoint and it’s gargantuan object model. This made SharePoint a very specialized skill-set that stood off to the side on its own. It’s lack of support for standard web-development practices made it difficult for new developers to learn – or to even want to learn.

Fortunately, this has changed.

SharePoint 2013 has joined the rest of the web-development world – supporting standard technologies such as REST, and languages ranging from .NET to Perl, PHP, Ruby, etc. JavaScript is now a first-class citizen. Gone are the days when “doing SharePoint” required extensive, arcane knowledge. For developers, SharePoint is now just another data store accessible via a robust, REST-based API.

In this full-day session, SharePoint MVP David Mann will introduce the SharePoint REST API and show how it can be used to build client-side applications using JavaScript, utilizing popular frameworks such as Angular and libraries such as JQuery, common tools like Node, Bower, Gulp and Yeoman, as well as rich-client applications using C#. This includes both on-premises installations of SharePoint as well as cloud-based environments such as Office 365.

Bring your laptops as this is a hands-on session. No SharePoint experience is necessary, but basic programming skills would be a big help. This is a great opportunity to add SharePoint to your toolkit, or to take your SharePoint skills to the next level. Individuals and teams are welcome.

I’m still tweaking the material, but here is the current agenda:

  1. Introduction & Getting Started (including why SharePoint? )
  2. Setting up the Environment
  3. Setting up the Environment (Lab)
  4. Tools & Frameworks
  5. Tools & Frameworks (Lab)
  6. The SharePoint REST API
  7. Hello (SharePoint REST) World (Lab)
  8. CRUD Operations
  9. CRUD Operations (Lab)
  10. Provisioning
  11. Provisioning (Lab)
  12. Language Agnostic – C#, Ruby, [Insert favorite language here]
  13. Language Agnostic (Lab)
  14. Wrap Up and Next Steps

I’ll post more details as we get closer.

To follow along with the labs, you’ll need:

  • a laptop with Visual Studio (2013 or 2015)  installed

That’s it.  You will not need SharePoint installed

Partial Classes to the Rescue!

I’m working with a fairly large codebase – a few of my base classes have several thousand lines of code.  Not huge, but certainly unwieldy when you need to be hopping around the codebase.  There’s just no great way to organize everything.  While some folks eschew regions, I find them useful when used sparingly and what I’ll call “correctly”.  In other words, regions never go inside a method, that can quickly lead to a mess; but they’re useful to group a bunch of related members and be able to quickly hide them.  In some cases, those members can and should be moved to a separate class, and in those cases that’s what I do.  But in some cases, a separate class doesn’t make sense.  Regions do.

But even that isn’t enough sometimes.  In my current codebase, I have a bunch of interfaces which my various classes implement.  Each interface defines 5-10 members, so they’re pretty tiny, but even that can get unwieldy.  My core base class implements 5 of those interfaces, which means that it has something around 40 methods just to implement its interfaces – that’s not getting into some of the core logic for that abstract base class, just its interface implementations.  It also has a bunch of private methods and properties which it needs to do its job.  Wading through all of that code can be a headache sometimes.  Worse, I’m still a little old fashioned and sometimes I want to (gasp) *print* some of my code to be able to analyze it and draw circles and arrows while working on it.  Regions don’t help when printing – everything collapsed inside the region gets printed.

That’s where partial classes come in. 

I’ve started breaking my larger classes into partial classes – one file for each interface.  Now everything related to ISecurable or IStorable, for example, is on one place.  Each code file is now closer to 7-800 lines of code instead of 3-4000.  Much easier to work with. 

The best part is, neither Visual Studio nor the compiler care.  The compiler happily combines the separate files together into the exact same MSIL as if they had been all in one big file to begin with.  Visual Studio doesn’t miss a beat, either.  Not only does it have no trouble with the separate files, it still shows me proper Intellisense across files:


Furthermore, Visual Studio is smart enough to show me all of the members of my class, even those defined in another file from the one I’m currently working in, and it even shows them dimmed so I know they’re in another file:


Other Visual Studio functions, such as Peek Definition, Go to Definition, Find All References, etc., continue to work as well.

Typically partial classes are used to separate generated code from developer-written code.  Other folks use them to allow multiple developers to work on the same class at the same time.  This is just one more case where partial classes provide real value.  I know some folks will disagree with this, and that’s fine.  To each their own.  To my mind, partial classes, like regions, provide significant value when used appropriately and in moderation.

One final point, I organize my partial classes a little differently than I think other folks might, and I think this helps keep things straight.  Every partial class in my code base is in a folder named for the class.  Each file of the partial class has the same base part of its name – the name of the class, but then it also includes the interface implemented in that file.  Here’s a view of Solution Explorer showing one of my partial classes (RepositoryItem):


Each interface gets its own file, and then there’s RepositoryItem-Core, which contains everything else for the class.

Typescript Webinar–Part 1

I just wrapped up my latest webinar on the Critical Path Training free webinar series – this time on Typescript.   It was pretty well attended – about 60 people if I saw the attendee counter properly.  Smile  I think the session went OK – it started out a little slow but then picked up and as usual, I had way too much content to fit into a 45 minute session (allowing time for Q&A).

If you missed the live session, the recording is available here:

Anyway, as promised, this post is a summary of the material I covered and the first of what I hope to be several posts on the subject of Typescript and SharePoint.  I do need to revisit my JavaScript series, which has been sorely neglected over the past few months, and see how it needs to be refocused to fit into the brave new world of Typescript.

What Is Typescript?

So, first of all…what is Typescript?  From the website, we learn that:

Typescript is a language for application-scale JavaScript development.
Typescript is a typed superset of JavaScript that compiles to plain JavaScript.
Any browser. Any host. Any OS. Open Source.

Great.  That and $5 will buy me a cup of coffee.  Honestly, that description barely scratches the surface of Typescript.  Personally, I prefer this as a definition:

Typescript is a language and accompanying tools that support robust, professional development using JavaScript for cross-browser, cross-host applications of any size.  It facilitates the creation of standards-compliant JavaScript (ECMAScript) in a type-safe, easy-to-use manner which can be quickly grokked by most managed code or other professional programmers.

I think that is a far more encompassing definition. 

Now on to the good stuff.

Getting Started with Typescript

To get started with Typescript, you first need to install a couple of tools.  First, you’ll need the Visual Studio plug-in and I highly recommend Web Essentials (for more than just Typescript):

Web Essentials:

VS Plugin: (If you don’t use Visual Studio, Typescript is also available for Sublime Text, Emacs and Vim.  My guess is that if you’re doing SharePoint development you use VS…)

With those installed, you’re ready to go.  You can now create a SharePoint project (Farm, Sandbox or App – doesn’t matter) and add a Typescript file to it:



After you first add the Typescript file to your project, you’ll see it in Solution Explorer:


(Notice that there is no accompanying .js file yet)

Once you compile (which could be as simple as just saving the .ts file, depending on how you’re environment is configured), the appropriate .js files are created and nested under the .ts file in Solution Explorer:


The configuration settings to pay attention to are in Tools|Options|Web Essentials|Typescript:


Most are pretty straightforward and can be left at their defaults for now.  I’ll explore these options in more detail in a later article.  The only ones I like to make sure are set a certain way are “Keep Comments,” “Compile on Save”,” and “Minify generated JavaScript” – I make sure they’re all set to TRUE.  Believe it or not, we want to leave “Compile all Typescript files on build” set to FALSE.  We’ll address that next.

To make sure that our Typescript code is compiled into JavaScript at the proper time, we need to go through a little hack for any SharePoint projects.  Rob Bogue spells it out here: and the end result looks like this in your .csproj file:


The highlighted part is what we added.  Note that you’ll need to perform that little hack for every project in your SharePoint VS Solution that needs to compile Typescript.

The last thing you’re going to want to do is remove the .ts file from your deployment package – there’s no sense including it in the package – neither SharePoint nor the web server would have any idea what to do with it.  Doing this is simply a matter of deleting it from, or commenting it out of, the Elements.xml file:


Now we’re finally ready to begin… 

The Typescript Editor

The Typescript editor is a two-paned affair.  You type your Typescript on the left, the right is a preview of your generated JavaScript:


Each and every Typescript file you add will have some sample code included with it.  This is great while you’re learning but just an annoyance when you’re actually trying to be productive.  I hope this changes in the RTM of the tooling.  If, for some reason the tooling doesn’t change at RTM, or if deleting the sample code every time gets on your nerves, you could just create a Text file and change the extension to .ts.

After pondering over the sample code for a few minutes, go ahead and delete everything in the left hand pane – Ctrl-A | Delete will do the trick.  Now save your .ts file and, assuming you set your options as specified above, the JavaScript code in the preview on the right hand side will disappear as well.

This is probably a good place to end part 1 of this article.  We’ll pick up with Part 2 shortly covering our first baby-steps into writing Typescript code.  I’ll leave you with some resources to help you learn basic Typescript.  Part 2 will review some of that quickly and then move on to SharePoint-specific Typescript code.


Typescript Language Specification:

Pluralsight Typescript course:

My webinar slides:


That’s it for part 1. 



SharePoint Tips

Last night at the final @TSSSPUG meeting of 2011, Michael Mukalian and I presented an informal couple of sessions covering various tips that we’ve learned over the years of beating our heads against the SharePoint wall.  Here’s a quick review of what I covered…


JavaScript & JQuery Intellisense

Add the following lines to the top of your .js files to get intellisense for JQuery and the Client OM:

/// <reference path="C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14TEMPLATELAYOUTSMicrosoftAjax.js" />
/// <reference path="c:IntellisenseFilesjQuery-1.7-vsdoc.js" />
/// <reference path="C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14TEMPLATELAYOUTSSP.core.debug.js" />
/// <reference path="C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14TEMPLATELAYOUTSSP.debug.js" />

Note that the path in the second entry is to a folder on my dev machine where I put the –vsdoc files downloaded from the JQuery website.  Adjust your path as appropriate.

Developer Dashboard

I did a quick overview of the DevDash and why it is useful.


There’s NO REASON not to use this tool.  Just Do It.

O365 FxCop Rules

If you’re doing Office 365 development, this is another must-have tool:

Resolving Sandbox timeout errors

On a development box only, add the following entry to your HOSTS file to improve the responsiveness of your sandbox process when it is starting up:

Adding a "close" link to the Status Bar with your status messages

var statusId=SP.UI.Status.addStatus("Title", "Hello World Status Message <a href=’javascript:SP.UI.Status.removeStatus(statusId)’>[Close]</a>");

Using PowerShell in the VS Pre/Post Deployment steps

%windir%sysnativewindowspowershellv1.0powershell -file "$(ProjectDir)MyPSScriptFile.ps1" where MyPSScriptFIle.ps1 contains your PoSh commands to be run


Using LinqPad as a snippet compiler/tester

LinqPad: (free)


Hopefully folks got some value out of the session.



CKS:API update and AOP

CKS:API is still moving along. It’s a little behind schedule due to work constraints.  Two new developers have joined the project and I’m looking forward to some additional eyeballs on the code to help tighten it up.  I’m also looking into Aspect-Oriented Programming (AOP)  to overcome one of the big hurdles in CKS:API – littering all of that logging code throughout your codebase.  I’m hoping that AOP will work as advertised (I’m using PostSharp, which seems to be the standard for AOP in .Net) and if it does, then parts of CKS:API will be refactored to make this an option.  PostSharp has a free “community” edition so it won’t necessarily shut anyone out.  You’ll still have the option of manually inserting the logging code on your own, so this is not a show-stopper requirement for using CKS:API if we do go that way.

Stay tuned…more details to come…

Questions from my Pro-Dev webinar

There were a few questions that I didn’t get to answering at the end of my Critical Path Training webinar last week.  I apologize for not getting to them during the webinar, but I was already running significantly overtime, so I’ll address them here:

Q: Does use the Microsoft Practices LoggerProxy project?

A: It does not directly use the Patterns and Practices material as there is a lot of “extra” stuff included (Service Locator, etc) that would have made just using the logging and exception handling more difficult.  Our goal for CKS:API is to be a lightweight, largely independent collection of resources that do not require a lot of additional architectural elements.  The P&P guidance is an excellent resource and if you find yourself needing a large percentage of it, I would strongly recommend looking at using it in its entirety.  All of that said, some of the approaches and code practices in CKS:API are quite similar to the P&P guidance.


Q: How about Microsoft unit testing framework that comes out of the box with visual studio 2010, is this an option when it comes to SharePoint?

A: The unit testing tools in Visual Studio can be used to manage and run your tests for SharePoint.  This is what I used in my demos.  Due to some complexity in testing SharePoint, you need some facility to create mocks to stand in for standard SharePoint objects in order to eliminate your dependency on SharePoint.  In the demo, I used TypeMock Isolator for this, but you could also use Microsoft’s Pex/Moles.


Q: How do you recommend using SpGuidance in code? because that puts more overhead and more objects runtime..

A: See my answer to question #1 above.


Q: Is CKS API logging service works in MOSS 2007 ?

A: Unfortunately, no.  I may introduce this in the future, but right now there are no plans for it.


Q: What about TFS ?

A: TFS is not directly related to unit testing.  It is a source code repository, team management/collaboration, project management tool (among other things).  Using TFS on a SharePoint project is not very different from using it on any other project.  I’ll be blogging about this more in the future.


Thanks to everyone who attended.  As usual, I tried to jam too much information into the session so I feel like I glossed over some stuff.  I’ll be posting more detail here on my blog in future articles.