JavaScript for the C# Developer Part 2 – Variables and Scoping Rules

Next: JavaScript for the C# Developer Part 3 – Functions

If you are reading this post I probably don’t need to tell you what a variable is, but the chances are good that you misuse variables in JavaScript because as you learned in the first lesson, JavaScript is not C#!

Implied Global Variables

In JavaScript variables are declared using the optional var statement. The var statement declares a variable and optionally assigns a value. If you forget to declare a variable and simply use it, JavaScript will happily allow you to do so and will create a global variable as a result!

This behavior would be dangerous in any language, but it is especially dangerous in JavaScript because of <script> elements. Generally speaking, you have no way of knowing which other scripts might be used with your script when you are programming. This means that global variables are inherently dangerous. There is nothing to ensure that another script doesn’t make the same mistake and create accidental global variables. Two scripts using the same global variable name can easily collide and create interesting bugs.

Consider the script found here: which illustrates the issue.

In this sample I have a script block that uses the variable I which is treated as a number. Elsewhere I also use a variable named I to which a string is assigned. Clicking the button yields:

It does so because I is not a number, NaN. In this example it is easy to see why this is so. In real life this type of defect can cause unpredictable behavior when scripts collide and can be very difficult to find! Another form of this problem is when you simply mistype a variable. If you transpose some characters JavaScript will happily make a new variable for you on the fly of global scope instead of producing a runtime error or warning.

Generally speaking JSLint will catch this problem and warn you that you have created an implied global variable.

C# has Block Scope, JavaScript does not!

Consider the following C# code:

This code results in a compile time error because C# has block scope and the code tries to use I outside of the block in which it is declared (the for block).

Similar code in JavaScript works.

Even though i was declared in the for block, it exists and is accessible even after the for block completes.

JavaScript doesn’t have block scope, it has function scope. Parameters and variables defined in a function are not visible outside the function, but a variable defined in a function is visible anywhere within the function. A function acts as a container and functions can contain other functions (more on that in another lesson). The key point is that a function can see the variables defined by its parent and other ancestors. These variables are ‘up-visible’ but because variables defined in a function outside the function, variables are not ‘down-visible’. This concept is easy to understand with this sample:

Within the function inner() the variable input is visible because it is defined by its ancestor function top(). However innerVar is not visible from top() nor is top()’s named argument input visible outside the function top(). In both cases the test for undefined returns true because those variables are undefined at that scope.

Global variables are an Illusion

The fact that functions can see up implies that there must be an outer container that holds everything. This container’s name is window and it is not a function but an object. The window object provides the runtime context and contains properties that let you access things like the document and location as well as methods like alert and events like onload. Therefore, creating an implied global variable by forgetting var is the same operation as adding a member to window.

Global variables are just like local variables but they are local to window and thus visible everywhere to all of the functions contained by the window.

The Most Common Scope Related Error

Thus far you’ve seen two ways to create members on the window object, accidently by forgetting var and deliberately by using window. There is another far more common way that developers can create global variables and unintended name collisions.

Consider a page like this:

Where script.js is as follows:

Both the page and the script use variables named x and y and both use the var keyword. The browser reads and executes script.js first because it is at the top of the page. The script block at the bottom of the page executes last. When it executes the function foo() the output is not 4 but is abcd. This is because whenever you declare a variable that is not contained by a function it is attached to window!

This is easily the most common and dangerous issue with JavaScript code we encounter at our customers. The next post will cover functions and how we can use them to protect our variables.

Next: JavaScript for the C# Developer Part 3 – Functions


Author: Doug Ware

Author: Doug Ware

JavaScript for the C# Developer – Part 1

Next: JavaScript for the C# Developer Part 2 – Variables and Scoping Rules

In my recent post, My First Thoughts on SP 2013 – What does it mean for developers?, I wrote, "If you can’t work effectively in client side technologies, you will no longer be able to legitimately claim to be a senior or architect." Some of my friends expressed some trepidation about this new model on twitter. For example:

I’ve gotten quite a few requests to do a video or turn the presentation, better JavaScript in just 60 minutes, into writing. I decided writing would be fun and this is the first post in the series.

There are many great tutorials out there about JavaScript development so I wouldn’t be surprised if this one has very few readers after the first couple of weeks because I don’t expect the search engines will put this anywhere near the first page of results. So if you like this series some links would be very much appreciated.

The original presentation and this series of posts is designed to help .NET developers get up to speed on JavaScript (although I got some great praise from a Java developer who said it was ‘a revelation’). Because of this some of the terminology and the concepts I describe are technically wrong or are oversimplifications that I build on later on. If you already have a deep understanding of JavaScript and you submit comments to complain about these details there is a good chance I won’t approve them if they spoil my narrative.

Lesson 1 – JavaScript is not C#

If you are reading this there is a good chance you use JavaScript the same way I did prior to making a commitment to understand it back in 2010 – your JavaScript looks very similar to C# and you commonly copy bits and pieces from tutorials you find on the Internet. You can get away with this because the syntax of the two languages is similar because of their common ancestor, C. However, the two languages have very different rules and require different techniques. Comparing C# to JavaScript is not an apples to oranges comparison because they come from the same family. Instead it is more like comparing oranges to limes – similar in many respects but also very different.

The biggest difference is that C# enforces certain good coding practices via a complex and robust system of types centered on classes. Conversely, JavaScript is a deceptively simple language that does almost nothing to prevent accidental injuries.

When using JavaScript one must take care else one may cut off one’s foot.

Essential tools

If you find this series of posts worthwhile and want to follow along there are a few tools I recommend you should use to help follow along and test out concepts.

  • An up to date browser with its associated developer tools. My favorite is Firefox + Firebug, but I use them all.
  • JSFiddle

JSFiddle is an awesome website that lets you create, test, and share JavaScript. It supports many popular JavaScript frameworks including Mootools, jQuery, Prototype, and Knockout.js. It’s hard to beat as a learning aid; I think it’s much better than Visual Studio for tinkering.

Instead of embedding a screen shot into this post I will share a link to a simple ‘Hello World’ fiddle I wrote: Follow the link and click Run to see the awesome demo in action. By the time you finish reading this series of posts you’ll completely understand the syntax I used in my script, but for now I just want to point out some of my favorite JSFiddle features.

JSFiddle incorporates a few features that make it indispensable for me which I pray that Visual Studio’s completely deficient JavaScript editor will someday include. All are accessed via JSFiddle’s simple toolbar.


The TidyUp tool reformats your JavaScript to make it readable with proper indentation and line feeds. I often go to JSFiddle simply to paste in a poorly formatted or minified script and use TidyUp to make it readable.


JSLint is a code analysis tool for JavaScript written and maintained by Douglas Crockford who is also the author of JavaScript: The Good Parts, a book I highly recommend.

Unlike C# which you must compile before you can execute code, JavaScript is interpreted. If you do something silly with your C# the compiler will tell you. The same sorts of mistakes in JavaScript manifest as runtime errors. JSLint helps you catch those mistakes just as a compiler does for C#. However, unlike a compiler, JSLint also criticizes your style and points out potential problems with your code. In this respect JSLint is like FxCop, but it’s feedback is much better than FxCop.

I use JSLint on every bit of JavaScript code I write and I credit it with being the most important factor in my evolution as a JavaScript programmer. I only have to be told a few dozen times before I quite making a mistake!

Versioning and Sharing

If you have an account and you are signed in you can create and track multiple versions of your fiddle. Even if you aren’t signed in, you get some support for this via the Save function.

That’s it for now…

I think this post is long enough. The next post will be an introduction variables and scoping rules. Stay tuned!

Next: JavaScript for the C# Developer Part 2 – Variables and Scoping Rules

Author: Doug Ware

A Comparison of the Core CSOM Classes and Microsoft.SharePoint in the Sandbox

The Gaps in the Apps


I’m already starting to see conversations here and there about sandboxed solutions versus the new Apps model in terms of capability. I spent today drilling into both the core Microsoft.SharePoint namespace in sandboxed mode and the CSOM equivalent, Microsoft.SharePoint.Client. I started by writing a simple console application that used reflection to give me the public types and their members in both namespaces. Then I pulled that data into a database and started crunching it to see what I could learn.

In the server-side namespace there are 214 public classes and enums. In this portion of the CSOM namespace there are 289 public classes and enums. As I looked a little closer I realized that the organization of the two models is different. One reason the CSOM namespace has more members is because some of the members are located in other namespaces in the server-side object model. Also, CSOM includes many classes intended for use by apps and sandbox naturally lacks these.

Before I go any further I want to make sure I point out that I am only comparing the core namespaces in this post. CSOM is far larger than sandbox because it supports most of the SharePoint Server features whereas sandbox only supports SharePoint Foundation. Furthermore, CSOM has much UI functionality and the sandbox has very little.

Since the namespaces are organized a bit differently, I decided to focus only on those classes that exist in both namespaces. It turns out that there is much less overlap than I expected. There are only 96 classes and enums in common between the two models. However, those 96 classes include those for webs, lists, list items, content types, fields, and queries.

In the SharePoint 2013 Preview – Apps or Crapps? post I asserted that a key factor in a developer’s decision to use CSOM will be the ability to rewrite traditional server-side code with CSOM. To this end, I believe it is critical that there be parity between the server side OM and CSOM for the core classes. Therefore my next step was to compare the members of the overlapping classes to identify properties and methods. In the server OM the 96 classes I analyzed contained a total of 6,856 public properties and methods. In CSOM the corresponding classes have a total of 5,086 public properties and methods. The server side implementation of these classes contains 1,770 more public properties and methods than the CSOM equivalents. Of course CSOM has many properties and methods not found in the server OM. Unfortunately, for the analyzed classes I found 3,984 members in the server OM without analogs in CSOM.

Note: If a property is missing in CSOM it typically counts as two members in my analysis because reflection emits a get_property and a set_property. The doubling of properties in the count makes the gap look bigger than it really is.

It’s what’s behind the numbers that matters

Some of the gaps I identified in the core objects are simply a result of different conventions between the two models. I also assume that they took the opportunity to remove deprecated or out of date members. Unfortunately, for the most part the difference is because the core CSOM classes as they exist in the preview are far less powerful than they must be if Microsoft expects corporate developers to adopt this model.

Microsoft has a lot of work to do between this preview and the final release.

Download the findings and see for yourself

You can download a spreadsheet with the final data from here: The workbook contains two spreadsheets. The first shows my mapping between the two namespaces and the second lists the members that don’t have obvious equivalents in CSOM.

Why this is important

It seems unsurprising to me that the gaps I have identified exist as most of them are related to provisioning and configuration. This is the oldest portion of CSOM and it was developed during a cycle when Microsoft was encouraging the use of sandboxed solutions. Sandboxed (and farm) solutions can execute feature event receivers to do this work. Apps require the use of remote event receivers to do the setup you can’t pull off with CAML. Remote event receivers can only use CSOM and these gaps must be narrowed if not closed completely for Apps to be viable for a broad range of typical corporate SharePoint solutions.

I still believe CSOM is awesome

… but it is clearly incomplete. When you look at the spreadsheet you might be inclined to reject the model, but I think that would be a mistake. This is the last post I plan to write for this build concerning the gaps in the apps. From here on out I will be covering JavaScript and CSOM on the UI side. I believe the story there is much more satisfying and is extremely compelling.


Author: Doug Ware

SharePoint 2013 Preview – Sandboxed Solutions: Dead or Not Dead?

In my previous post I referred to this MSDN article: Apps for SharePoint compared with SharePoint solutions,, which says that sandbox solutions are deprecated.

That is not the only article that contains the guidance. Build farm solutions in SharePoint 2013,, says the same thing.

What does ‘deprecated’ mean?

To summarize deprecated indicates that some new feature (the App model) supersedes an older feature (sandboxed solutions) and that the old feature still exists for backward compatibility but may be removed in some future release.

Controversy! Do they really mean it?

Over on Twitter and Yammer there is some lively discussion about whether or not Microsoft really means this and if they will change this text. A number of people who I respect maintain that the documentation is wrong and that they will change it.

I am positive they are mistaken. Here’s why.

One of the key reasons I wrote the SharePoint 2013 Preview – Apps or Crapps? post is that the day before I wrote it the Apps for SharePoint compared with SharePoint solutions article contained text that said sandboxed solutions are deprecated and that new ones are no longer supported on Office 365.

In spite of my well known disdain for sandboxed solutions, I have a number of complicated ones and that text really pissed me off alarmed me. In fact my first draft of the apps or crapps post contained a variety of colorful words and phrases with regards to my feelings.

The next day, when I sat down to finish the post there was a comment from Microsoft at the bottom of the page that said something like: "the text about sandboxed solutions is wrong, we will update this article soon."

I was happy to see that comment and I eagerly waited for the update. The text you see today contains the correction. It still says they are deprecated, but it no longer says they are no longer supported.

I can only conclude from this that the articles say exactly what Microsoft means for them to say.

Thank You SharePoint Team!

Regardless about how anyone feels about the new App model or the deprecation of sandboxed solutions, I think we should all be very grateful for the transparency. Other teams have recently created and allowed a great deal of ambiguity with regards to the future of certain development tools. They left the poor Silverlight developers flapping in the wind for months!

Regardless of the blowback they get from people unhappy about the decision, I think they have done right by us by being honest.

Should I Stop Developing Sandboxed Solutions?

If you are intending to target the Office 365 marketplace or adopt an in-house SP2013 marketplace you have no choice for those solutions. Everyone else does. Sandboxed solutions work exactly in SP2013 as they do in SP2010. I am unable to find any differences in terms of anything added or removed. The complete lack of new features alone convinces me they are completely serious about deprecation. My belief is that once people understand the App model they will gladly make the change from sandboxed to Apps. I plan to write more about why I believe this over the coming months.

Whether people should change from farm solutions to the App model is another question entirely. I have serious doubts, but I have not made up my mind about that yet.


Author: Doug Ware

SharePoint 2013 Preview – Apps or Crapps?

The SharePoint 2013 beta came out less than 60 hours ago and in less than 24 hours I saw this tweet on twitter.

It’s an easy joke to make and one that I’ll probably make myself during difficult debugging sessions. Still the hype machine is in full swing around this new mode of development. A good example is this article from CMS Wire: SharePoint 2013: 5 Reasons Why the New App Model Will Make Everyone Happy.

Microsoft wants you to Build Apps

But they have a credibility problem!

Consider this bit of advice from this MSDN article: Apps for SharePoint compared with SharePoint solutions.

(Develop an app whenever you can)

This is pretty unambiguous; the new App model should be my default choice. But, it reminds me of something from the past.



So the advice from 2010 was that everyone should build sandbox solutions as the default. The new version must really take sandbox solutions to the next level, right?

Yep, last versions new hotness is this version’s old and busted, and everyone is still building farm solutions.

Why the Sandbox Architecture was Bad

The sandbox architecture was fundamentally flawed. I discovered this during the last beta when I spent a few weeks building a non-trivial sandbox solution. I wrote about my feelings in a post title SharePoint 2010 Sandbox Solutions are Bad. It was reposted to End User SharePoint and sadly is still on the first page of search results if you search for ‘SharePoint 2010 sandbox’.

I was really irritated when I wrote that article, but to summarize my two biggest issues were that UI development was very difficult due to the sandbox restrictions and that the sandbox model lacked an answer for high-trust scenarios.

In short, the tools were insufficient for building business applications on SharePoint.

What about Apps?

So the question on everyone’s mind is: are they Apps or Crapps? Let’s start with the case that they are not Crapps.

They are Apps

The first question is: can you build a good UI? Sandbox made this difficult because it blocked access to the Microsoft.SharePoint.WebControls namespace. It was server side code without access to any of the server side controls. Apps also lack access to this namespace because they prohibit all custom SharePoint server-side code. However, as you saw in my previous post there are now mechanisms for rendering just about everything with JavaScript templates. The completeness of the CSOM API’s and the robustness of the templates and documentation will be the keys to general acceptance of this mode of UI development. There seem to be some obvious omissions at the moment, in particular with regards to the ribbon, but keep in mind that this is a preview and we are a long way from release.

The second question is: can you effectively perform high-trust operations (things the current user isn’t allowed to do) with apps? If you build a provider hosted or auto hosted app you can write code to respond to remote events from SharePoint based on whatever permission set you require assuming the installer of the app agrees. Even better, the server that handles the events and performs the high trust operations can be written in any language assuming it can use some form of the client side object model (CSOM). There are even people out there using CSOM with node.js.

The App architecture is beautiful in my opinion especially for solutions that will be widely installed. Imagine having hundreds of installed versions of a sandbox solution that you need to update. You’d have to update hundreds of sites. With important code on a shared app server you simply don’t have this problem. Even for point solutions the fact that the UI code now goes in the actual UI via HTML, CSS, and JavaScript instead of through ASP.NET web forms (which are really showing their age) makes apps very attractive.

They are Crapps

People Like Farm Solutions!

Say what you will about the server side API’s, they are quirky, ornery, and often frustrating to use. You can build powerful farm solutions and they are the standard approach for most SharePoint developers. If Microsoft wants people to move to CSOM they must make it worthwhile and as painless as possible. This means that when a developer decides to port some existing code to CSOM she shouldn’t hit walls because a given commonly used property or method is inexplicably missing from CSOM.

For example, as of today you can’t persist changes to property bags or hide fields via the ShowIn*Form properties; CSOM lacks functions for these. Once again this is a preview release we are talking about and they have time to fill these little holes in the API. But if they don’t I expect they will have a hard time convincing developers to change models.

I also don’t think they can get away with a repeat of the sandbox situation and retain any credibility. As our former president said, "fool me once, shame on — shame on you. Fool me — you can’t get fooled again."

This same need for completeness extends to the UI itself. I think it is telling that at the moment the SharePoint hosted sample apps they have in the marketplace are all based on Access Services. They do not have a sample that displays and uses standard collaboration site elements tied together to solve a business problem. Access Services is pretty cool, but if my app has a calendar or contacts list I want it to integrate with Outlook and be standard SharePoint goodness, not some half-assed custom thing I built in Access. I want my application’s web to be a normal SharePoint web with my specific customizations.

Speaking of app webs…

App Webs are Stupid

When you have a SharePoint hosted or hybrid app you get an ‘app web’. An app web lives outside the host web in a special isolated web application and site collection. The idea is that the app web isolates the app for purposes of permissions and management. If the user decides they don’t want an app they can uninstall it without affecting the host web.

This sounds great, but the problem is that a SharePoint site is not a phone!

I don’t believe users will make a distinction between a site that has a document library with their important documents and a normal site created independently of an App as a subweb or freestanding site collection. If you build a specialized app that facilitates the majority of an individual or group’s work the host web becomes this thing the user has to traverse to get where they really want to be. Worse still, if you have many such sites based on an app they will exist outside of your carefully defined IA and site topology under a bunch of funny looking URLs.

Guidelines aren’t Published Yet

It must be said that everything I just said might be wrong because it is possible for an app to do things to a host web. If it has permission to do so it could theoretically pave the host web and replace its contents with the app specific lists and libraries. However, your app must meet guidelines from Microsoft and pass review for inclusion in the new marketplace. My suspicion is that paving the host web, at least in Office 365, is a big no-no.

Alas, that is pure speculation. So until the marketplace guidelines come out you have some risk if you decide to start building an app today.

It doesn’t Matter if they are Apps or Crapps

There is a third fundamental reason I disliked the sandbox architecture. The UI model was very different and features were subtly different. In spite of Microsoft’s promises to the contrary you could not take a non-trivial sandbox solution, deploy it as a farm solution, and expect it to work. You had to think differently and design differently.

I don’t think the same is true for most apps. This is counter intuitive so let me explain…

A typical SharePoint solution consists of:

  • Features for provisioning
  • UI
  • Event handlers (feature, web, list, item)

From a logical design standpoint a provider hosted or auto hosted app is exactly the same thing. The physical difference is that the code runs in a different place using a set of API’s with a different syntax or even a different language.

Unlike the sandbox, it is possible to write identical code in the UI of a page (or client rendering template) for a farm solution as for an app. However, it is up to you to do so because you can also do the farm code the old way, in which case it won’t transfer.

And so, my point is that you should be approaching your UI the same way regardless of the mode of development. This means you can begin to move toward apps without ditching farm solutions.

Finally, it is worth pointing out that in on premises deployments you can mix and match solution types and build hybrid farm/app solutions and even hybrid farm/sandbox/app solutions if you want. I haven’t tried it, but it seems like it should be perfectly possible for a web service that responds to remote app events to be hosted in SharePoint and deployed as a farm solution, but that is super speculative as the devil is in the details.

The Devil is in the Details Indeed

So, I guess what I am saying is that it is too soon to tell if they are Apps or Crapps, but they have the potential of being awesome if Microsoft provides a complete API that makes it possible for people to meet their requirements. If they don’t I am certain that people will happily keep writing farm solutions and only those motivated by the (also as yet unproven) marketplace will build Apps.

That would be a shame.


Author: Doug Ware

Understanding Templated Client Rendering in SharePoint 2013 Beta

It’s another hot and rainy day here in Atlanta. It’s a good thing I have the beta to keep me inside!

The other day I wrote about the importance of JavaScript in SharePoint 2013. As I said, much of the server side rendering is replaced by client side script and while the old-school XSLT still works, you should consider it deprecated. To appreciate what I mean, consider the JSLink property which is now exposed via the object model and feature CAML for a wide variety of items including Fields, Content Types, and Views.


The JSLink property allows you to specify a JavaScript file that is responsible for rendering the item in the browser. As you can imagine, the JavaScript for a list view is pretty complicated. So, instead of jumping in tp the deep end of the pool today I will focus on customizing Search rendering for now. To follow along at home you will need to get search working and add some documents to a Team site and the same documents to a Publishing site. Alternatively, you can do this on Office 365.

Search Result Types

The improvements in Search in 2013 are incredible. Among the improvements is that SharePoint displays a hovercard when you mouse over a result.

If I had an Office Web Applications server installed, this hover card would also include an interactive thumbnail of the document itself so I could look at it without opening it!

The hovercard and the items listed in the search results are rendered via JavaScript. You can create rules to affect the display based on the items’ content types and even by field values. To see this, open a Team site in the browser, open the Site Settings page and click the Result Types link.

The Manage Result Types page lists all of the types with specific rendering. Each has rules that when true cause an item to use the given template and the order determines which rules get checked first. SharePoint applies the first match it finds. For the rest of this post I will use the Microsoft Word template.

The Microsoft Word result type specifies that

~sitecollection/_catalogs/masterpage/Display Templates/Search/Item_Word.js

will format the results for Word docs.

In my example I am using a document that has sections. The amazing new search indexer extracts that information from the document and displays it in the hovercard under the heading ‘Take a look inside’.

The rendering instructions for Word item hovercards is in the same location as Item_Word.js and its name is Item_Word_HoverPanel.js. I can edit this file with SharePoint Designer 2013, but in the grand tradition of SPD the way it’s done is a bit goofy. If you try to navigate to the folder that contains the templates through Master Pages in the Navigation pane it will say there are no files there, but you can get to them via All Files.

I am going to edit Item_Word_HoverPanel.js and add an inline style to change the color of the Take a look inside heading. Remember kids, inline styles are only good in simple demos! In real life use a style sheet!!!

If I refresh my search results and check the hovercard I can see it worked.

You can examine Item_Word_HoverPanel.js to get an idea of what is going on here, but there is a better way.

Design Manager: Edit Display Templates

Publishing sites provide an amazing new feature called Design Manager. Many people are writing about it so I will skip the high level discussion and get right to the point! But first, have some links:

Publishing sites can generate the rendering JavaScript for you based on HTML templates. If you aren’t using publishing in your site you can still use as a publishing site as a development tool to cheat and create the JavaScript! The HTML templates are far easier to read and are an excellent place to start understanding what you need to do for your own custom rendering templates.

Open up a publishing site in SPD 2013 and use All Files to navigate to /_catalogs/masterpage/Display Templates/Search. You will see that the publishing site has many more files than the team site did and that each JavaScript file has an associated HTML file. To customize the hoverpanel I can simply edit the Item_Word_HoverPanel.html file and SharePoint will generate the correct JavaScript. This time I will make the heading purple.

Open the file and edit it. You will immediately see that the template is much easier to follow than the straight js version. Pay special attention to ctx object – it is the key to custom rendering. You can see that ctx gives access to the current item and that it provides methods for rendering via:

  • ctx.RenderHeader(ctx)
  • ctx.RenderBody(ctx)
  • ctx.RenderFooter(ctx)

I edit the file as follows:

And the result looks like this:

Conclusion – Letting SharePoint do Some of the Work

If I use the script debugger of my choice, in this case FireBug, I can see the resulting script.

Pretty cool eh!? I could then use this template in my Team site as desired.

This tutorial has barely scratched the surface of client rendering. As of this writing the SDK still isn’t out, but fortunately I had the unfortunate circumstance to reverse engineer much of the list rendering in 2010 so I will keep writing about it over the coming months until we get some good documentation. This stuff is important enough that I expect we’ll see some decent materials on the subject in the SDK.


Author: Doug Ware

Configuring Visual Studio 2012 for SharePoint 2013 and Office 2013 Development

Update: These instructions also apply to the RTM version of VS.

This seems to be one of the questions I am seeing most on twitter (@DougWare) so even though this information will probably be easy to find very soon as the developer center content appears, I thought I’d post what I did for those of you who just can’t wait.

Thanks to @robwindsor for helping me get started by pointing me to this page: It has a section on this subject:

The problem is that I couldn’t find the link to which this refers. So, to get this working follow these steps. Note that these instructions are for On Premises development and you don’t strictly require a SharePoint installation if you want to develop using the new Apps model.

  1. Setup SharePoint 2013 Preview
  2. Install Visual Studio 2012 RC
  3. Download and install the Web Platform Installer 4.0 RC
  4. Launch the Web Platform Installer and search for Office
  5. Install Microsoft Office Developer Tools for Visual Studio 2012 RC – Preview (it installs the others you see in the screen shot)

  6. Download and install the SharePoint Server 2013 Client Components SDK from here (Note it doesn’t have any documentation or samples in it as of this writing)
  7. Launch VS 2012 and have fun!



Author: Doug Ware

My First Thoughts on SP 2013 – What does it mean for developers?

There has been much anticipation around the new version of SharePoint. Rumors have been swirling for months and people have been trying to read the tea leaves in the published protocol documentation to understand what the new version is all about. I fully expect my RSS reader to be clogged up with numerous posts about the many exciting changes. No doubt there will be plenty of redundant ‘check out feature x’ and ‘how to install it’ type posts. And so, in what probably is a futile exercise I will try to go meta and say something interesting to my primary audience which is of course the SharePoint development community.

ASP.NET is Dead

If you jump into the 15 hive and start poking around you will quickly discover that SharePoint still uses features to define farm elements. If you look at the services you will see that the sandbox code service is still there. It will be clear that all of the skills you have so laboriously invested in over the years still apply. Why then do I say that ASP.NET is dead (besides tricking you into reading)?

Dig a little deeper though and start looking at the pages in the browser and you will quickly come to realize that just about all of the interesting pieces of the user interface make heavy use of JavaScript and HTML 5. Go back to the 15 hive and have a look in the Layouts folder. Filter the files with sp*.debug.js. You will probably recognize some of the files, but most will be new to you. You will quickly see that the client side object model (CSOM) is many times bigger than it used to be and it now has libraries for all of the popular SharePoint Server features.

Next, open a site and navigate to the Site Settings page. Click the Result Types link under the Site Settings heading. What you are looking at are the various display templates for items in search results. View any of them and notice that the Display template URL is a JavaScript file.

By now you might be noticing a pattern.

Go back to your sites home page. Edit it and edit the Documents Web Part (assuming you have a Team site). Expand the Miscellaneous heading and look at the last property. Its name is JS Link. With it you can specify a JavaScript to render the contents of the view in the browser in whatever format you choose instead of using the server side control to do the work.

Viva La JavaScript!

I believe that if you have some search results pages or data Web parts that use XSLT they will still work, but a few things seem to be clear.

The first is that JavaScript is now a first class citizen. Many things that we were forced to do on the server are now possible in the client. This means that you truly can greatly decrease the amount of ASP.NET code you write and you can use the many amazing JavaScript UI frameworks that have emerged over the last couple of years to do some amazing things.

The second is that if you downloaded the beta to get ready to develop new solutions for 15, you better be working on becoming a skilled JavaScript developer. Many of the senior people (architects and developers) that I have worked with over the last couple of years frankly suck at client side technologies because they’ve been able to assign that work to others. Those days are at their end. If you can’t work effectively in client side technologies, you will no longer be able to legitimately claim to be a senior or architect.

The third is that if you lean on SharePoint Designer to write your XSL or HTML you will be disappointed. Open up SharePoint Designer and edit a page. Do you see a tab for Design View? No, you don’t. I hope they see the light and add it back before RTM, but even if they do the current lack of this functionality makes a pretty big statement. All is not lost though; there are some big improvements for professional Web designers. In a publishing site you can use HTML from a wide array of other and much better tools.

So What Else is New?

Go back to the Home page and insert a Web Part into the page. Select the Content Rollup category. Do you see Content Query there?


Instead you see Content Search. Pop open Central Admin and go into the Search service application. Edit the Local SharePoint Sites content source. Scroll down to the Crawl Schedule and notice that you now have the option for continuous crawling. The Content Search Web Part isn’t based on CAML queries – it’s based on search and it is way more powerful as a result. Guess how you can customize the rendering of the results? Hint: The answer starts with ‘Java’ and ends with ‘Script’.

SP2013 now has the capabilities of FAST and the improvements here are just huge.

I’ll be writing extensively about JavaScript rendering and CSOM, but until then if you are a C# developer and want a decent crash course via slide deck, download my Code Camp (and SharePoint Saturday) talk on better JavaScript in just 60 minutes.

.Net 4

Even though JavaScript is central to the new version you will, of course, still write plenty of .Net code. From what I have seen though, the core of the object model is pretty much the same. SharePoint 2013 runs on .Net 4 and I was going to write about it, but there is already a great set of posts here and so I will just share the link.


If I were on the ball I’d have a whole series of posts on the new workflow engine and on the new app model ready to go today. Alas, I’m not on the ball and so you’ll have to get that info elsewhere if you want to read about them today. The next couple of months will be busy!




Author: Doug Ware