Creating Provider Hosted Apps? Don’t Forget the Client Secret Expiration

Bo is a Principal Consultant for ThreeWill. He has 18 years of full lifecycle software development experience.

Just a quick heads up for anyone that has done Provider Hosted Apps for Office 365. If you used AppRegNew.aspx to get your Client Secret, don’t forget it expires by default after one year.  I was reminded of this recently when one of our really smart customers noticed some strange behavior in their QA and UAT environments.  Thanks to her (yes, you are awesome Beth Vinson) troubleshooting chops she was able to catch this before it went into production.

The link below provides helpful tools (PowerShell) to identify when client secrets will expire and how to replace them. Also with PowerShell you can set it to expire up to 3 years max instead of the default 1 year.

We are building a provider hosted app called Trove right now.  Danny Ryan mentioned on an internal Yammer discussion that getting a new client secret as maintenance is part of their installation guide – we had to put this in our installation guide for Trove –

Eric Bowden mentioned in that same discussion that we’re creating an app for Trove in the Office store. The Client Id for Office store apps can be created to expire after 1,2, or 3 years.  He’s also looking into creating a warning screen to catch this maintenance task before it becomes a problem.

Did you get caught by this?  Any tips you would add?

Share a comment below.


read more
Bo GeorgeCreating Provider Hosted Apps? Don’t Forget the Client Secret Expiration

Ten Reasons Why Office 365 and Azure Made Me a Fan Boy

Bo is a Principal Consultant for ThreeWill. He has 18 years of full lifecycle software development experience.

I recently worked on an on-boarding solution for a customer that was built as a cloud based application using Microsoft Azure and Office 365.  It’s what Microsoft refers to as a provider-hosted app for SharePoint, and it is all the rage these days.  Being a Microsoft developer for about 15 years, I’ve learned to be a little cautious of the newest things being pushed out by the Microsoft marketing machine.  However, after working on very real world challenges using Office 365 and Azure, I think all hubbub is well deserved.

In the on-boarding application, our customer had some very typical requirements that most companies might have including:

  • Public facing internet site where anyone can register and apply for a job
  • Highly complex and very business specific onboarding process
  • Simple and familiar UI for managing applicants from hiring through termination
  • Routing to different queues based on an applicant’s current state
  • Need to support user based events and time based events
  • Need to integrate with external third-party systems during onboarding

In addition to the typical requirements, our customer had some more unique but not uncommon challenges to deal with:

  • Very small IT staff responsible for supporting many users and technologies
  • Seasonal hiring model with large peaks and then periods of low activity
  • Need to manage seasonal employees individually or in batches
  • Desire to very easily change the workflow process over time

Obviously there are some “off the shelf” products that can handle some of these requirements, but many times they are not as customizable as desired.  Other times they can cost more than a custom solution due to licensing costs over time.  Finally, they may not integrate out of the box with Office 365 where many employees are already doing work.

Since our customer was already using Office 365 for collaboration and Azure for other applications, a provider hosted app was a natural fit for them.  It allowed for the flexibility to satisfy all their requirements, provided the services to be an enabler for their IT Staff and the UI familiarity for their internal stuff.  In the white paper The New Business Operating System: Combining Office 365 and the Microsoft Cloud Ecosystem to Create Business Value I think Pete Skelly summarized it best in the sentence “The New Business Operating System (NBOS) enables businesses to leverage commodity based IT Services and enables customizations to enhance business value.”

That sentence really says so much; I thought I would break it down into some specific reasons and examples on how the New Business Operating System helped our customer with their solution and made me a fan.

Five Reasons Office 365 Added Value to Our Solution

  1. Do More with Less – With a small IT staff, using Office 365 is really a no brainer. The Software as a Service (SaaS) model means no infrastructure to manage and no software to install/maintain.
  2. Familiar User Interface – For internal users, Office 365 made sense as the UI since it is already familiar from other activities such as document management and collaboration.
  3. Ease of Management – Built-in support for things like user management, security, lists and views means the small IT staff can easily manage the user experience for internal users just like they do for other functionality in Office 365.
  4. Workflow Engine – With a workflow engine available in Office 365, time based events like status changes and notifications after a specific period of time is easy.
  5. Ease of Customization – UI elements such as pages and the ribbon in Office 365 can be easily customized to integrate custom functionality while still looking like it’s built into the platform.

Five Reasons Microsoft Azure Added Value to Our Solution

  1. Enterprise Level Management and Support – Again, with a small IT staff, using a Platform as a Service (PaaS) makes a lot of sense from a management standpoint. In Azure, backup and recovery, monitoring and scalability are easily managed without needing extra tools or software.
  2. Flexible Compute Power – The nature of a seasonal hiring solution is also a perfect fit for Azure because you can easily deal with “Predictable Bursting” (The New Business Operating System: Combining Office 365 and the Microsoft Cloud Ecosystem to Create Business Value) by increasing resources during peak periods and reducing during low periods. If you had to deal with this on your own infrastructure, it would likely mean lots of idle hardware much of the time.
  3. Technology Choice – Since Azure is a platform to host applications, it provides the flexibility to develop an application exactly as envisioned by a customer and in technologies, known or comfortable. In our solution, we stayed within the Microsoft stack including ASP.NET MVC, Entity Framework, and several JavaScript Frameworks, but you aren’t limited to these at all.
  4. Ease of Deployment – In Azure, it is also extremely easy to package and deploy the application. This means developers can spend their time on business functionality and creating business value. Our application could be deployed to an environment like QA and UAT in just a few clicks.
  5. Robust Platform – Azure isn’t just for web apps and databases either. It’s a much larger platform that supports things like a service bus where an application can use queues and messages to make the application more robust, scalable and responsive even during unexpected peaks.

As you can probably tell, I’ve become a fan of creating solutions using Microsoft Azure and Office 365 as the platform and services to build upon.  I look at how our customer’s resources are now enhancing the application and managing thousands of applicants with just 2 people working on the application only part of the time.  In a traditional on premise application, there is no way I can imagine it would be possible for just 2 people to support the same application and be able to continue to add business functionality.

SharePoint is a web application platform in the Microsoft Office server suite. Launched in 2001, SharePoint combines various functions which are traditionally separate applications: intranet, extranet, content management, document management, personal cloud, enterprise social networking, enterprise search, business intelligence, workflow management, web content management, and an enterprise application store. SharePoint servers have traditionally been deployed for internal use in mid-size businesses and large departments alongside Microsoft Exchange, Skype for Business, and Office Web Apps; but Microsoft’s ‘Office 365’ software as a service offering (which includes a version of SharePoint) has led to increased usage of SharePoint in smaller organizations.

While Office 365 provides SharePoint as a service, installing SharePoint on premises typically requires multiple virtual machines, at least two separate physical servers, and is a somewhat significant installation and configuration effort. The software is based on an n-tier service oriented architecture. Enterprise application software (for example, email servers, ERP, BI and CRM products) often either requires or integrates with elements of SharePoint. As an application platform, SharePoint provides central management, governance, and security controls. The SharePoint platform manages Internet Information Services (IIS) via form-based management tooling.

Since the release of SharePoint 2013, Microsoft’s primary channel for distribution of SharePoint has been Office 365, where the product is continuously being upgraded. New versions are released every few years, and represent a supported snapshot of the cloud software. Microsoft currently has three tiers of pricing for SharePoint 2013, including a free version (whose future is currently uncertain). SharePoint 2013 is also resold through a cloud model by many third-party vendors. The next on-premises release is SharePoint 2016, expected to have increased hybrid cloud integration.

Office 365 is the brand name used by Microsoft for a group of software plus services subscriptions that provides productivity software and related services to its subscribers. For consumers, the service allows the use of Microsoft Office apps on Windows and OS X, provides storage space on Microsoft’s cloud storage service OneDrive, and grants 60 Skype minutes per month. For business and enterprise users, Office 365 offers plans including e-mail and social networking services through hosted versions of Exchange Server, Skype for Business Server, SharePoint and Office Online, integration with Yammer, as well as access to the Office software.

After a beta test that began in October 2010, Office 365 was launched on June 28, 2011, as a successor to Microsoft Business Productivity Online Suite (MSBPOS), originally aimed at corporate users. With the release of Microsoft Office 2013, Office 365 was expanded to include new plans aimed at different types of businesses, along with new plans aimed at general consumers wanting to use the Office desktop software on a subscription basis—with an emphasis on the rolling release model.

read more
Bo GeorgeTen Reasons Why Office 365 and Azure Made Me a Fan Boy

Making App Only SharePoint Calls Without Being Launched from SharePoint

Bo is a Principal Consultant for ThreeWill. He has 18 years of full lifecycle software development experience.

Making App Only SharePoint Calls

If you’ve done much development with provider-hosted apps, you’ve likely become at least vaguely familiar with some of the components you get to make your development life a little easier.  First, the Token Helper class was introduced to simplify authentication and authorization between SharePoint and your remote app.  Then came the SharePoint Context helper which built upon Token Helper to give you better and more consistent support for dealing with things like high-trust apps versus low-trust apps and allowed you stop worrying about all that authentication nonsense.  With ASP.NET MVC it has become as simple as throwing the SharePoint Context Filter attribute on your controllers or actions that need to talk with SharePoint and alakazam you can pull the client context out of your hat.

What if some users who are accessing your Provider-Hosted Application are not in SharePoint?

Wait, what? Now why would I want that? Suppose for a moment that you want to have a web application in Azure that any user on the internet can just visit, register, fill out some information and then kick off a process that is managed by people in your back office. Then suppose you want to run your back office process in Office 365. Seems pretty reasonable for a use case, right? You get all the crunchy goodness of SharePoint for your back office team with lists, views, workflows and more. Then you get the flexibility, power and complete control for your customer facing portal with Azure, ASP.NET MVC and that whole technology stack. I like to think of this as a provider-hosted application pulling double duty since the back office team will still be useing the app by launching it from SharePoint and external users will access the app without coming from SharePoint.

Sounds easy enough, will SharePoint Context just provide all this magic for me?

Unfortunately, the short answer is no. It was not built to handle this scenario and has some serious expectations around what sort of baggage you are carrying along in your query string. Clicking on your app in SharePoint does what Sean Hester refers to as the “identity dance” in part 4 of his series on SharePoint 2013 App Models Considered. The dance starts with appredirect.aspx and ends with a POST back to what you’ve defined as your start page in the AppManifest of your SharePoint App. The POST includes an SPAppToken form variable and if you used the {StandardTokens} token as part of your defined start page, a fully baked set of query string values including SPHostUrl, SPLanguage, ClientTag, ProductNumber, and SPAppWebUrl.
Chakkaradeep Chandran was very specific in his post that introduced MVC support for apps for SharePoint when he said, “SharePoint Context classes encapsulate all the information from SharePoint.” and the SharePoint Context Filter attribute additional processing to get the standard information when redirected from SharePoint to your remote web application…”.

So where do I go from here?

The good news is that SharePoint Context and its use of the Token Helper provides us with all the examples we need to follow and understand so that we can “roll our own” and allow an Azure web application to talk to SharePoint. Before going much further though, it is important to reiterate that because the users, that are accessing Azure are not valid SharePoint users it will mean that our SharePoint app must be able to make app-only calls to SharePoint. This just means we will be using an app-only access token to make calls to SharePoint and our AppManifest must be configured to allow app-only calls.

Update your SharePoint App

In your SharePoint App project you need to check the “Allow the app to make app-only calls to SharePoint” and configure any other permissions your app might need.


Azure Web Application

Before diving into the changes that need to be made to allow the remote web application to make these app-only calls, I should mention a few pieces of information that are important to keep in mind. In our scenario the provider-hosted application will serve only a single Office 365 SharePoint App at a time. Once the SharePoint App is installed the host web URL, app web URL, and realm will all be known to us and do not need to be dynamically determined at runtime.

Make use of configuration

Maybe it’s a case of old habits dying hard, but the most obvious place to put our static entries seemed to be the web.config. You’ll notice that the provider-hosted app already establishes this pattern by putting the ClientId and ClientSecret in there to be used by the Token Helper class.


In the above screen shot, you’ll notice several key/value pairs that aren’t in your web.config for a standard provider-hosted app. I’ll go into more detail about how we use each when I put it all together a little later, but for now I’ll describe each and provide some background.

  • HostedAppHostName
    • Although this key/value pair isn’t put into your web.config by default, it is also important to point out that the method ReadAndValidateContextToken in Token Helper will attempt to use this configuration value as a fall back if a null value is provided for appHostName to that method.
    • This is the URL authority (host name or IP address) of the remote web application making the calls into SharePoint. SharePoint Context figures this out by using URL authority from the HTTP request, and it must match what was provided as the App Domain when the app was registered (/_layouts/15/appregnew.aspx).
    • Since Visual Studio registers an app automatically for you when deploying using F5, it may not be obvious what you should provide for this value. If you are developing and testing locally, it will likely be localhost:44308; but once you are packaging, deploying and testing in Azure, it would be something like unless you are using a custom domain.
    • If you are ever unsure you can check /_layouts/15/appinv.aspx by providing your app id (aka ClientId) and verify that your App Domain matches to HostedAppHostName or the URL of the remote app if you don’t put HostedAppHostName in the web.config.
    • 19635_appinv
  • SPHostUrl
    • This is the URL of the SharePoint site that is hosting the SharePoint app. SharePoint Context dynamically figures this out based on the query string values when launching the app from SharePoint. In our case this URL will never change for a given environment such as development or production, and we won’t be using SharePoint Context for external users.
  • SPAppWebUrl
    • This is the URL of the SharePoint app. SharePoint Context dynamically figures this out based on the query string values when launching the app from SharePoint. This URL does change when installing new versions of a SharePoint app, and therefore, we always make sure it is current in our app settings for our Azure web application.
    • You can get this URL by launching the app after it has been deployed.
  • Realm
    • This is a unique id specific to your Office 365 tenant and only changes if the SharePoint app is installed in different Office 365 tenants. Token Helper internally uses this configuration value when it can.
    • There is also a method available called GetRealmFromTargetUrl in case you don’t know your realm until runtime. Typically that would only be the case if your SharePoint app was in the App Store and your Azure web application was used by many tenants. If you look in the code for this method, it relies on a try catch to get the realm. And as we all know, exception logic is expensive, so if you know your realm it’s probably best to avoid using this method if you can.
    • If you want to find out the realm for the tenant where your SharePoint App will be deployed you can go to the /_layouts/15/appprincipals.aspx off of your host web and look at the App Identifier, the last part after the @ will be your realm.

Put it all together

Once you have the configuration in place, the code to get a SharePoint client context object you can then use to make app- only calls is actually very simple. There is really just one small method needed to get a client context object for a given host web or app web url.


As you can see, the code retrieves the target realm from configuration and then uses the Token Helper to get an app only access token and use the token to get your client context. You probably noticed that aside from realm none of the other configuration values above were used to get the client context. Since this is a helper method, SPHostUrl or SPAppWebUrl would be passed into this method depending upon which context we want to establish. HostedAppHostName is actually used inside the TokenHelper.GetAppOnlyAccessToken along with the ClientId and ClientSecret to create an access token request. The rest of the code in the catch block is just used to inform if a request failed that a configuration value may be incorrect.

Now that we have GetClientContextForUrl, it can be called with an app web url (or host web url) and perform any work that requires the client context. In the sample below it’s using the email address for a user that is in SharePoint to get their SharePoint user id so that data from end users can be appropriately assigned and routed to back office users.


As you can see, it doesn’t take a lot of code to be able to take a provider-hosted app and allow it to talk to SharePoint even when it is not launched from SharePoint. This is really thanks to the foundation established in the Token Helper class and understanding how to make use of it for this scenario. You can also continue to use the provider-hosted app and the user app context established when the app is launched from SharePoint in the more common examples you may have already seen.

With this approach you may find yourself dealing with lots of unique configuration values if you have a team of developers and many different deployment environments like QA, UAT and Production. Fortunately, these hurdles can be easily managed and overcome using web.config transforms which I hope to provide another blog post on soon to show how you can control all that configuration chaos in a manageable way.


read more
Bo GeorgeMaking App Only SharePoint Calls Without Being Launched from SharePoint

SharePoint 2013 App Models Considered – Part 5

Sean is a senior consultant at ThreeWill. He has over 16 years of experience developing web applications. His primary passions are in usability, group collaboration, project and process automation, data visualization, and social media tools. He is an MCSD in Web Applications and an MCTS in SharePoint Application Development.

It’s all downhill from here. In the previous posts in this series, I’ve offered an overview of the whats and wherefores of SharePoint 2013’s new app model and taken some detailed looks at three variations I’ve worked with:

  1. In the first post I talked about the new app model and how it marks an important shift away SharePoint’s historic app dev trends.
  2. In the second post I reviewed App Web Apps, the first of two SharePoint-Hosted app variants, and discussed why I think they fall short for most real-world solutions.
  3. In the third post I reviewed Host Web Apps, the second of two SharePoint-Hosted app variants, and discussed why I think they fall short for most real-world solutions.
  4. In the fourth (and previous) post I reviewed Provider-Hosted Apps, and talked about why I believe they represent the strongest option for SharePoint development going forward.

In this final post of the series I’m going to wrap up some loose ends and provide a scorecard tool you might find helpful if and when you need to evaluate SharePoint’s app model options for your organization.

Another Perspective on Provider Hosted Apps vs Farm Solutions

Before I wrap up this series, I want to take another look at Provider Hosted Apps. This time I want to compare them to Farm Solutions, i.e. the go-to standard for heavy lifting with SharePoint prior to 2013. Here’s a section from my previous:

Yes, Farm Solutions still have advantages at the edges. If your customization needs are light, Farm Solutions will get you there much quicker, especially for seasoned Farm Solutions developers. They may look odd and have poisonous claws, but they’ll win those short-distance footraces. On the other end, if your app needs deep access into the SharePoint API, beyond what CSOM offers, Farm Solutions are the only way to get there. Between those edges lies significant territory where the 2013 App Models are competitive: apps with more than a handful of user stories that require customization or domain logic, but don’t need an all-access pass to the SharePoint API.1

Let me unpack this opinion a bit. You may have picked up on the subtext that I’ve been frustrated with the stale, backward nature of SharePoint development since I started working with it in 2009. Nevertheless, I appreciate—deeply respect, really—the power that SharePoint brings to solutions out of the box. If your solutions can benefit from one or more of SharePoint’s core capabilities (content management, collaboration, search, provisioning, etc.), then building on top of SharePoint makes tremendous sense. Farm Solutions provide access to “guerrilla” customizations that are perfect for bridging that last mile gap between SharePoint’s out-of-the-box features and what your users need to be truly productive and happy. And most long-term SharePoint developers are proficient with guerrilla tactics.

The flaw with this approach, in my experience, is that many organizations want (need?) to push customizations way further than the last mile. Many of my recent clients have needed solutions that wind up looking more like web apps running out of SharePoint’s _layouts folder than a simple collection of coordinated SharePoint features and artifacts (content types, lists, web parts, etc.). I don’t blame my clients for this; I think SharePoint contributes to this delinquency in some significant ways2.

  1. SharePoint’s a Jack-Of-All-Trades. SharePoint packs a lot–probably too many–features and services into one set of similarly branded SKUs. From one perspective, SharePoint is really more of a collection of loosely-related services centered generally around “collaboration.” From another, it’s an accomplished provisioning engine, complete with self-service capabilities. From my favorite perspective, it’s a great package of services to plunder in custom applications. All of this disparate potential makes it exceedingly attractive for product owners to over-reach and ask SharePoint to do something it doesn’t do all that well, which spells heavy customizations.
  2. User’s Dislike SharePoint’s User Experience. People tend to like applications that have focused areas of competency and well-designed and defined ways of completing certain tasks. SharePoint tends to lean the other direction, supporting a breadth of malleable activities out-of-the-box. This makes it perfect for power users who can directly harness that flexibility and/or are adept at grassroots policy management, or for rapid prototypes and versions < 2 of a solution. But this flexibility translates to “vagueness” in the hands of less experienced users, and they frankly don’t like it. SharePoint’s long release cycles and technology lags (review the app dev timeline again for details) don’t help, either: SharePoint’s user experience feels perpetually behind the rest of the web by 3-5 years. And again, all this spells a high demand for customizations.
  3. Scope Creep is Natural. No matter what anyone else tells you, scope creep is the natural state of projects. This is at least as true with custom application development as with other business domains. Change is inevitable, and the app dev world is *filled* with unknown unknowns. Most projects I’ve participated in have experienced significant scope changes prior to the first release. Those that make it to second and third releases will almost certainly see scope changes north of 100% relative to original scope features/stories, code base…however you want to measure it. That SharePoint app that starts out as a handful of features can quickly grow to need custom web services and pages. That’s the point where ASP.NET MVC starts like a better–and cheaper–option.

In short, SharePoint offers some amazing, high-value features…they’re just trapped inside a difficult-to-approach, Swiss Army chimera. Or platypus, if you prefer. The problem is teasing out that value frequently requires you to customize more heavily than guerrilla development tactics can sustain. This is why Farm Solutions quickly loose ground to the Provider Hosted App model.

I’ve mocked up a graph based on estimates from my project experience that compares the productivity of these two options3

Dev Effort Curve Comparison

This chart compares the rate of change in level of effort for Farm Solutions and Provider-Hosted Apps as customization increases.

Following are some talking points for the chart:

  1. On the left side of the chart are projects with low customization requirements. For these projects, the clients are okay with most of what SharePoint brings to the table out-of-the-box. They typically have a small user base, and the user base tends to have a high concentration of power users. Projects internal to IT are a great example. They maximize the “OotB Advantage”.
  2. As the customization needs increase, moving right across the graph, SharePoint tends to get more difficult to work with, while Provider-Hosted apps enjoy a shallower LoE slope due to their high-productivity toolset and their affinity[note] for crafting modern and focused custom user experiences.
  3. At some level of requirement complexity the LoEs cross, and Farm Solutions begin paying a “Customization Penalty.” I’ve seen cases where this penalty becomes extreme; it’s frustrating to watch and even more frustrating to work with.

The App Model Scorecard

Since I’m now solidly in faux-quantitative territory (beware!), I’ll segue to my final thoughts for the series: the App Model Scorecard.

During the early stages of our internal discussions about the relative merits of the new App Model, the discussions (and my own thinking) were more conjectural and ambiguity-prone than I was comfortable with presenting. To give the process more rigor and consistency, we developed a scorecard that scored different app models across multiple features and concerns that are typical with real-world SharePoint applications. In all, we identified just shy of 50 separate concerns across 8 major app dev categories, and scored each app model (or other architectural choice) on a scale of 1 to 5 based on their fitness or ease of achieving that concern. The individual scores were discussed and vetted internally at ThreeWill, and I believe there is general agreement on them, but at the end of the day, if you spot some specious scores I’m the one who has to answer for them. I’m okay with that—bring on the rebuttals!

Rolled-up by category (i.e. the high-level view), the average scores look like the following:

SharePoint App Model Capability Score Card

The capability score card displays the relative fitness or ease of use score for each app model/architecture across 8 high-level app dev categories.

If you’ve read or skimmed the series to this point, these scores shouldn’t surprise you:

  1. The heavy 2s and 3s for the SharePoint-Hosted variants reflect their limited usefulness, constrained by the all the “Where They Fit” questions I presented in post 2 and post 3.
  2. In contrast, Provider-Hosted Apps enjoy *almost* the same level of fitness and productivity of Farm Solutions.
  3. As pointed out in the chart, the “Biggest Delta” is the ground Provider-Hosted Apps give up in productivity and tooling, most of which center on the difficulties with securing communication across the Provider-SharePoint boundary (it really is more painful than it needs to be).
  4. On the other hand, Provider-Hosted Apps do enjoy one area of advantage in the area of User Experience—UXes that put users at ease and get them productive are much easier with an MVC app using modern client tooling than building on top of SharePoint.4

While it might be interesting for you to see my/our scores for these app models, I’m actually more excited about what you might do with it. To that end, we’re giving away the original Excel worksheet we used to generate these scores. If you or your in-house SharePoint SMEs disagree with some of these scores (we know you/they will), here’s your chance to tweak them and evaluate your own posture toward the SharePoint 2013 App Models. I’d love to hear where you land (tweet @seansageek, leave me a comment below, etc.).

Conclusion and Download Our Comparison Spreadsheet

This puts the wraps on my SharePoint 2013 App Model blog series. I hope you’ve learned something, and even better if you’ve walked away with some free code and/or a scorecard tool. Since SPSATL we’ve been woodshedding ideas and proof of concepts related to smoothing our clients’ adoption of 2013 and the new App Model. New posts on those topics are coming soon. In the meantime, if you’ve got questions about anything SharePoint related, just let us know—we’re here to help.

Download a spreadsheet with all the details of the options we compared (with pros and cons of each) here.


  1. You can find this quote in context from my previous post in the “But I Don’t Want To Go To The Cloud” section.
  2. The opinions provided to support this point are not original to me, but I’ve observed them directly in many organizations, and in my experience they’re pretty widely held. A quick Google search will turn up a number of hits. One of my favorite recent blogs on this topic is “Why Do People Hate SharePoint?” from the EndUserSharePoint blog.
  3. I’m sad to admit I have no real-world numbers to feed this chart. I have shared it around internally at ThreeWill, and most of my colleagues agreed with the general concept it illustrates. If you happen to have real-world numbers across a statistically significant set of SharePoint projects and want to share it, I’m all ears.
  4. Apologies to the SharePoint User Experience team for this blunt assessment. They have a *very* difficult job at the conceptual level: Swiss Army chimera’s present a heavy UX challenge. SharePoint’s aging platypus architecture doesn’t help.
read more
Sean HesterSharePoint 2013 App Models Considered – Part 5

SharePoint 2013 App Models Considered – Part 4

Sean is a senior consultant at ThreeWill. He has over 16 years of experience developing web applications. His primary passions are in usability, group collaboration, project and process automation, data visualization, and social media tools. He is an MCSD in Web Applications and an MCTS in SharePoint Application Development.

Up to this point I’ve introduced some high-level considerations for SharePoint app development (part 1), and two App Model variants that don’t have real legs in my opinion:

  1. App Web Apps (part 2) are restrictive, offer reduced productivity, and create un-SharePoint-like data silos
  2. Host Web Apps (part 3) are restrictive, offer reduced productivity, and are frustratingly fragile (so far)

This brings us back to the thesis of this series:

The number of “real world” business cases where SharePoint-Hosted App Model variations make sense is very small; most solutions are going to require a Provider-Hosted app.

This post marks the inflection point in this series: for the first time I’m covering an App Model that I believe has serious potential. And the potential isn’t just serious; it’s broad and proven. The truth is, the Provider-Hosted App Model is just a SharePoint-flavored version of modern best practice throughout the rest of the industry: our custom code lives in app environments we control, and we consume other services via their public REST (or similar) APIs. This is the way developers build SalesForce apps. This is the way developers build LinkedIn apps. This is the way developers build Farmville. It has been the industry’s best practice for product integration for years, and SharePoint has finally caught up 1. Huzzah!

To wrap this back to my furry, duckbilled metaphor:

Breathe a sigh of relief and be glad! Now the platypus can stay happily in his backwater, and your app doesn’t have to crawl in with him just to collaborate.

As usual I’ll try to make this palatable and predominantly pain-free for the mildly interested (my entire audience?):

  1. Provider Hosted Apps Overview
  2. Real World Sample App
  3. What’s Good About Provider Hosted Apps
  4. What’s Bad About Provider Hosted Apps
  5. Where Provider Hosted Apps Fit
  6. “But I Don’t Want To Go To The Cloud…”
  7. Pro Tips for Provider Hosted Apps
  8. Notes

Provider Hosted Apps
As covered in my first post, one of Microsoft’s primary drivers for introducing the SharePoint 2013 App Model was to make SharePoint customizations cloud-friendly. To do this they had to get custom code off the SharePoint server. Period. The first two App Models we reviewed (App Web Apps and Host Web Apps) did this by completely eliminating server code from custom solutions. SharePoint 2013 offers a beefed up REST API, beefed up JSOM, and you can get a lot done in SharePoint with nothing more than that. Or at least it seems so on paper.

The difficulty with this approach is that getting rid of the server is a drastic move for most web applications. Most applications need server code for private logic, security, and/or to give the application “agency” beyond a user’s web browser request (i.e. for lifecycle events). And most web developers are more productive when they can write some part of their apps in server code.

So if your SharePoint app needs server code, but it can’t run on the SharePoint server, bring in another server!

This is the exact premise of Provider-Hosted Apps: let SharePoint focus on doing SharePoint things well, and bring in another “Provider” to host custom features and services. I’ll try to frame this in the physical-logical block diagram mash-up (with App Web and Host Web Apps provided for comparison):

Let’s cover the highlights:

  1. The SharePoint-Hosted App Remains. Whether you deploy anything inside it or not, your app needs this beachhead in SharePoint to provide an access point and to participate in whichever version of the “identity dance” you choose.
  2. The Provider Makes It Good. Okay, I’ll admit that’s rebuttable, but my opinion leans heavily in that direction. At any rate, the external provider defines this model, and that’s where I’ll focus my attention.
  3. BYO Web App. Your app is all grown up now. What dev stack are you going to use? Frameworks or services? 3rd Party Services? Dev environments? It’s all up to you.
  4. Server-Side Goodness, A La Carte. Being an adult means you get to order from the full menu. You can order a relational data store, or a non-relational one, or pig out with both and a side of your favorite message queue. Mmmm…message queueing.
  5. BYO Web API. I won’t go into to detail here, but SharePoint’s OAuth implementation is a bit non-standard, and SP.RequestExecutor is WAY non-standard. Many important browser frameworks work OotB with standard OAuth or REST, but break with SharePoint. Writing your own API may sound like a headache, but it’s one I’d gladly take versus the headache of shimming JavaScript frameworks. Besides, a clever app can find a number of delicious uses for a fresh API.
  6. Dump That Heavy Browser. Your app has a full middle-tier now, so the browser can eliminate the extra business logic burden, and focus on presentation logic, i.e. what it was designed for.

Are you hungry for a Provider-Hosted App yet?

The (Doubly) Real-World App
In my second post of the series, I mentioned that ThreeWill had rewritten the Fab 40 “classic” Absence & Vacation Request app as technology demonstration of an App Web App. I also mentioned that it turned out to have some glaring flaws due to the limitations of that model. In the wake of that and several other bad trips with SharePoint-Hosted variations, we decided to try another Fab 40 app, but this time as a Provider-Hosted App: Help Desk.

Following are some screenshots of the much-improved Help Desk application:


The features are stripped down, but under the hood this app has some nice specs: The server code runs ASP.NET MVC5, with Web API 2.0 providing services to the browser. In the browser it’s running Angular and Bootstrap for a SPA2 with a responsive user experience. This is a modern stack that is a pleasure to work with, and I don’t miss the platypus even a little bit.

In addition to that, it includes some key demonstration points that a new-to-Provider-Hosted-Apps developer will find useful. Things like application lifecycle event handling, and some helpers for identity management and navigating SharePoint security in both MVC and Web API controllers3. Trust me—those alone are worth the price of admission.

Just as we have for the Absence & Vacation Request app, we’ll be providing the full source code of this app for anyone who’d like it. It’s still too alpha to post to GitHub or similar, but you can request a zip of the code from me via email.

What’s Good
The Provider-Hosted App Model has a lot to recommend it, not only in comparison to the SharePoint-Hosted app models, but in some cases on an absolute level:

  1. Full Middle Tier. You gain so much here it’s difficult for me to overstate its value. Let me put it this way: remember the list of “bad things” about App Web Apps? This alone cancels out or significantly mitigates the first six of those seven issues. For most web developers, this will drive the value of Provider-Hosted Apps well past that of any SharePoint-Hosted variation. More on that below.
  2. Best-Of-Breed Dev Stack. You may have picked up that I’m a devout believer in the power of the right dev stack. Provider-Hosted Apps give you full control here, at every tier of your application.
  3. Design Freedom. The set of architectural and design controls for browser-hosted code has become significant, but it’s still tiny compared to what you can do when you have control over one or more servers or services. The only real restriction is you still need a SharePoint beachhead, but you have several choices on how you use it.
  4. High Availability. Remember my gripes about our downtime with SharePoint-Hosted apps? This is your best bet for high-availability customizations, period. Even more so than Farm Solutions, which have their own issues. More on high-availability below.
  5. Longer Reach (Into SharePoint). SharePoint 2013 has greatly expanded and improved its REST API, and expanded JSOM access with it, but CSOM can still scratch itches that REST and JSOM can’t. It’s nowhere near the coverage you get with Farm Solutions, but it covers a wide array of activities.
  6. Lifecycle Management (ALM). Seasoned JavaScript developers can manage ALM convincingly with tools like Jasmine or Mocha. But from my experience, most developers can get further faster with test automation, requirements management, and other ALM activities when they have access to the server tools of their choice in addition to these excellent frameworks.
  7. Performance Controls. When you only have code in the browser, your have meager controls for app performance. Adding a server or service to your mix opens up significant options. If that service happens to be running in a cloud environment, your control goes from significant to tremendous.
  8. Revenue Options. If you have any desire to derive revenue from your app, please don’t try it as a SharePoint-Hosted app. You’ve got no private IP (i.e. someone will steal your code), and very poor revenue controls. If you want revenue, the SharePoint-Hosted path offers nothing but headaches and heartaches.

What’s Bad
Nothing’s perfect, right? That’s at least as true with application architectures as anywhere else. Here’s what I find most troubling—or maybe not—about Provider-Hosted apps:

  1. More expensive than SharePoint-Hosted Solutions…Maybe. I concede that a Provider-Hosted app is going to have higher operational costs than a SharePoint-Hosted app4. But if you consider the big picture of how SharePoint apps provide value, and what drives costs in application development (hint: developer productivity is almost always a huge factor), the picture improves. If you’ve got questions about that math for a specific project, you know where to find me.
  2. More complicated than SharePoint-Hosted Solutions…Maybe. You definitely have more moving pieces and operational support requirements. But in my opinion you simplify your architectural and ALM picture because you’ve regained the most productive and mature part of your dev team’s stack: the server.
  3. More up-front effort required. Once the farm and site collections are configured for apps you can crank out a hello-world App or App Part about 15 minutes after you install the Office Developer Tools extension. For most organizations, getting the provider infrastructure setup and configured will take two to four weeks, varying by IT overhead.
  4. Steep learning curve. This will vary based on current skill sets. Anyone who’s been a full-time SharePoint developer for the last several years will need a significant firmware upgrade. Refer back to my app dev timeline—full-time SharePoint devs like me have been creating solutions with a strange brew of platypus, tribal knowledge, and black magic. The Venn diagram of Farm Solution dev skills and SharePoint 2013 dev skills has significant non-intersects:
    The SharePoint Developer's Dilemma

    The SharePoint Developer’s Dilemma

  5. Missing tooling & rough edges. We experienced some higher-than-expected pain with managing user identity and the SharePoint context, especially when moving our server code to the Session-less Web API controllers. As of this writing, the community is rallying around this issue with some community-sourced solutions, including the ones featured in the Help Desk Application.
  6. They give up ground to Farm Solutions. There are still a number of areas, especially in Farm administration, where Full-Trust code is required. I expect to see and recommend solutions that wrapper these basic functions in Farm features and then expose them via custom APIs. Only the logic that requires Full-Trust code will be deployed directly to the Farm; all other logic is free to move to the new App Model.

Where It Fits
In the previous checklists for App Web and Host Web Apps, they were all inclusive: you needed to be able to answer “yes” to ALL of the questions before I’d recommend that model. Except for the last two questions, the following Provider-Hosted App checklist questions are independently qualifying: if you answer “yes” to ANY of the first seven, I’d strongly recommend a Provider-Hosted App. Why are the last two questions exceptions? They’re crucial organizational gut checks .

  1. Your Use Cases Exceed UX. If your app has concerns beyond user experience (business logic, dependencies on external services, its own lifecycle, etc.), the extra security, privacy, and productivity will make this your best (or only) option.
  2. You Need Private Logic. You just can’t get there with an app written in 100% client-side JavaScript.
  3. You Need App-Specific Security. Other than the Task & Time Entry app, I can’t remember the last time I worked on an app that didn’t need some kind of app-specific security. And as demonstrated in the second post of this series, the lack of private, tamper-resistant logic in JavaScript makes real security unattainable. But on the server you can lock features down all day long. Sometimes without even coding5.
  4. You Need Complex and/or App-Specific Data. If your app needs complex relational structures or large data sets, SharePoint lists will disappoint you pretty quickly. Add a server, and you have tremendous storage options to meet all your data needs.
  5. You Have Strict Availability Requirements. JavaScript running in a browser against an API that’s still a bit squishy is no place for a high-availability app. Configure up some geographically redundant, load-balanced servers or services, use message queueing for your cross-service communication, and you’ve moved a couple of orders of magnitude up the high-availability food chain.
  6. You Want To Leverage Server-Side Code. If you have existing server-side customizations or libraries that you want to leverage, you need a server to host them. This might seem obvious, but it’s worth calling out because it’s an extremely prevalent issue. In spite of Atwood’s Law, there’s a lot of high-value, server-only code in the world.
  7. You Need Agency Beyond A Browser. Many apps have concerns that can’t be reasonably transposed to the app user browser request context: lifecycle events, scheduled activities, state monitors, batch processes, long-running asynchronous tasks, compute-intensive processes, etc.
  8. You Have Tolerance For Additional Complexity. Gut check #1: if you choose the Provider-Hosted path, you will own the care and feeding of another server or service. It very well may be a value-add that pays for itself, but it’s still another moving part. You should fully consider the implications of this.
  9. You Have Time To Learn. Gut check #2: if you saw the Venn diagram above, and you or your team are not already in the distributed app cognoscenti, then you’re going to be playing catch-up. If you’re a long-time SharePoint developer, my advice is to lean into it. You proved yourself once with your platypus-husbandry-black-magic chops. This will be better, and at the end you’ll have two sets of very marketable skills instead of one.

“But I Don’t Want To Go To The Cloud…”
Okay, then here’s my advice: don’t go to the cloud. At least not until you’re ready. And if you’re never ready, that’s fine, too. What’s the worst that happens? Microsoft goes all-cloud after the next SharePoint release, 6, and in 2026—WAY too far into the future to speculate on effectively—you’ll lose all support for SharePoint 20167. You’ll have better options before then. Heck, you’ll have multiple generations of better options before then. Keep your investment on-premises for as long as you think it makes sense for you.

The truth is, I’ve been purposely quiet on the On-Premises vs. Cloud issue throughout this series because I don’t believe it matters for a discussion about app models. I don’t think it matters because regardless of where your SharePoint infrastructure is located, I’d strongly urge you to plan your move to the SharePoint 2013 App Models now. Not because they’re shiny and new, but because they’re better—legitimately, straight-up better—for many applications, even those confined to private networks.

Yes, Farm Solutions still have advantages at the edges. If your customization needs are light, Farm Solutions will get you there much quicker, especially for seasoned Farm Solutions developers. They may look odd and have poisonous claws, 8, but they’ll win those short-distance footraces. On the other end, if your app needs deep access into the SharePoint API, beyond what CSOM offers, Farm Solutions are the only way to get there. Between those edges lies significant territory where the 2013 App Models are competitive: apps with more than a handful of user stories that require customization or domain logic, but don’t need an all-access pass to the SharePoint API. I estimate that 50-75% of the apps I’ve worked on for SharePoint 2010 could have been written as Provider-Hosted Apps, and almost all of them would have been better for it. Your mileage may vary, but it’s worth serious evaluation.

Before I move off this topic, I want to say a few words in favor of the cloud:

  1. Your data is *very* safe in the cloud. I’ll bet you a doughnut your data is safer in Azure or AWS than on your network. Cloud providers run tighter ships than the vast majority of internal IT organizations. That’s not a shot at your IT pros; it’s a realistic assessment of economies of scale and the value of focusing on core competencies. They stake their paychecks on a spotless security record, and they’re investing in it in ways which you can’t compete 9. No disrespect intended.
  2. There’s plenty of value in cloud hybrids. Maybe you have a data sovereignty issue. Or maybe you’re in a business where there’s value in the traditional subpoena process. Fine—but don’t throw the baby out with the bath water. Are there parts of your business that don’t require that coverage? Consider moving those to the cloud. Have you thought about solutions that outsource processes to the cloud but leave your data in place? These things are possible, and a great consultant can help you navigate complicated issues like this (hint: we’d love to help).

Pro Tips
Yet again, most of the pro tips from the previous posts (here and here) can be carried over. But now we’ve got some new server-side considerations. Some of these will be platform-agnostic, but I’m working with the explicit assumption that most SharePoint developers are going to favor .NET technologies. That will bleed through everything that follows, especially in the examples and supporting arguments.

  1. Learn From Others. There have been a number of trailblazers in this area, and they have tremendous insights (and code!) to offer. Not to slight anyone, or to state the obvious if you’re a SharePoint veteran, but these are the folks I’ve leaned on most heavily: Kirk EvansScot Hillier, Andrew Connell, Bas Lijten.
  2. Don’t Suffer In Silence. SharePoint developers, as brothers and sisters bound by the sacred vows of platypus-husbandry-black-magic, have significant simpatico and camaraderie. If you hit a tough issue, head to SharePoint StackExchange or tweet-out at somebody. Tweet at me (@seansageek) if you have to. If I haven’t covered it already in this series, I probably won’t know the answer, but I might know someone else here at ThreeWill or elsewhere in the community who will.
  3. Consider PluralSight. I can’t speak to all learning styles, but PluralSight fits mine very well. And for SharePoint developers committing to cross the chasm and join the cool kids, PluralSight has your back. Plus, if you want to maintain your SharePoint edge, Andrew Connell has hours of great content there, particularly for SharePoint 2013 workflow.
  4. Consider Dependency Injection and Inversion of Control. It’ll feel funny the first three or four times you do it, but using DI and IoC gives your app tremendous freedom and flexibility. And if DI and IoC are old hat to you, take a look at what IoC ninja Matt Honeycutt has done with StructureMap in his Build Your Own Application Framework with ASP.NET MVC PluralSight course. Yowza, that’s strong juju!
  5. Consider No-SQL Data Stores. If you’ve been in a SharePoint foxhole for years, No-SQL data stores like Mongo and Couch are the real deal at this point. If you need simple object persistence, check here first.
  6. Consider an ORM. If you checked your No-SQL options and couldn’t commit to that route, at least consider using an ORM like the Entity Framework or NHiberate. I’ve used both and found they’ve added tremendous value. Don’t spend time writing your own DAL if you don’t have to.
  7. Queue Activities for High Availability. If high-availability and recoverability is a concern, there are several good queueing options these days. Rabbit and Azure Service Bus Queues come to mind.
  8. Automate Your Testing. I’m not a TDD purist, but I am an automated testing evangelist. It takes time and discipline, but for most projects it pays huge dividends. Visual Studio’s own testing tools have made tremendous strides in the last several versions, and they’d get my nod as of now, especially if you’re a testing n00b.

Next Up: Conclusion & Next Steps
Have you already had your fill? Great! If not, I’ve got one last post in this series to top you off. The final course is dessert: I’ll draw some final conclusions about the SharePoint 2013 App Model, and offer you something for the road: a scorecard to help guide your thinking about which solution architecture offers the best fit for your applications.

Has this post given you heart burn? Let me hear about it! There’s always an open chair next to me in the comments or on Twitter (@seansageek).


  1. See my technology timeline from the first post for my take on how SharePoint has historically struggled to keep up.
  2. Single-Page Application
  3. These include customizations to the standard the SharePointContext and TokenHelper classes provided by Microsoft in the Provider Hosted App solution template. These customizations are necessary to extend access to the SharePointContext to Web API Controllers. This code owes a great technical debt to Bas Lijten–you can read more at his excellent blog on the subject here.
  4. Unless your needs are purely developmental, investigational or fairly trivial, in which case you might be able to skate by with a developer-oriented freebie from a friendly hosting provider.
  5. With ASP.NET MVC and Web API controllers, security can be as simple as marking methods with an attribute or two.
  6. There are exactly zero real indications that this will happen
  7. I keep hearing people say “SharePoint 2015”, but I’ve observed Microsoft release dates for a long time, and 2015 sounds stretch-y to me. It’s a judgment call.
  8. Male platypuses have poisonous claws. Yes, I’m running this metaphor into the ground.
  9. You can find the impressive details about Azure’s security posture here, and the even more impressive list of security certifications it holds here.
read more
Sean HesterSharePoint 2013 App Models Considered – Part 4

SharePoint 2013 App Models Considered – Part 3

Sean is a senior consultant at ThreeWill. He has over 16 years of experience developing web applications. His primary passions are in usability, group collaboration, project and process automation, data visualization, and social media tools. He is an MCSD in Web Applications and an MCTS in SharePoint Application Development.

In the first post of this series I introduced some high-level considerations about the new SharePoint 2013 app model. In the second post I offered my thoughts on App Web Apps based on my experience, and introduced the instructive but flawed Absence & Vacation Request app. In this post I’ll consider another SharePoint-Hosted App variation: the Host Web App.

As before I’ve tried to cut this into manageable chunks for easy digestion:

  1. Host Web Apps (vs App Web Apps)
  2. Today’s Real World Sample App
  3. Code Release Disclaimer
  4. What’s Good About Host Web Apps
  5. What’s Bad About Host Web Apps
  6. Where Host Web Apps Fit
  7. Pro Tips for Host Web Apps
  8. Notes

Host Web Apps (vs App Web Apps)
Host Web Apps share many similarities with App Web Apps. You can find a quick rundown of the structure of App Web Apps in my previous post. Before we get to a structural comparison, I need to point out the fundamental difference between the two: application permissions.

At install, every SharePoint-Hosted app presents a permission demand to the installer. Even App Web Apps, which don’t require any explicit programatic permissions to the Host Web, do require implicit permissions to access “basic information” from the Host Web. This covers things like read access to the Host Web’s site title and the names, IDs, and email addresses of the site users. Host Web Apps, by design/definition need broader explicit programmatic access to the Host Web. What they need and ask for varies by app, and can range from read-only access for a particular list to full administrative control of the SharePoint farm or tenancy (!!!). Compare the permission demand for the Absence & Vacation Request app to a demo app I created that maxes out the standard SharePoint permissions:


This should give you an idea of both how much control a Host Web App *could* have, and what the permission demand looks like on both ends of the spectrum. I think it’s safe to say that most people are going to have a stronger emotional response reading the permission demand for the second app than for the first.

Now let’s look at what these broader permissions mean for the structure of a Host Web App. Here’s a side-by-side block diagram comparison for both:


The differences are focused, but significant. I’ve tagged the top 3 in the Host Web App diagram:

  1. While Host Web Apps technically *can* deploy some SharePoint schema objects declaratively into the App Web, by definition they won’t, or if they do it will be a limited set. This is the defining factor for Host Web Apps: they are intended to work predominantly with objects in the Host Web.
  2. The application code–still 100% JavaScript running in the users’ browsers—makes API calls to the App Web, but they execute via an intermediary JavaScript class called SP.RequestExecutor. The SP.RequestExecutor’s “service”1 (on the SharePoint server) routes requests to the Host site. Intermediating the API calls serves a couple of purposes:
    1. The app web and host web are in sibling domains, so this solves the cross-domain scripting issue.
    2. The app’s permissions are checked here to make sure the REST or JSOM requests don’t exceed it’s permissions.
  3. While declarative deployments (via CAML) to the Host Web are still limited to App Parts and Custom Actions, a clever application *could* deploy or modify schema objects in the Host Web, Site Collection, or for the Farm or tenancy so long as it is granted sufficient permissions.

The structure of Host Web Apps is more complicated than App Web Apps due to their need to manage permissions and API calls across the domain boundary between the App Web and the Host Web. In the big scheme of web apps, it’s still relatively simple on paper. In practice, crossing that domain boundary solves several problems, but introduces a few more.

Today’s Real World Sample App: ThreeWill’s Task & Time Entry App
ThreeWill recently moved our internally hosted project Extranet from an on-premises SharePoint 2010 farm to Office 365. In the process we identified some user stories that would really benefit from customizing the OotB SharePoint experience. These mainly covered tasks that required managing and entering data across multiple SharePoint lists:

  1. As a project team member, I want to be able to create sprint tasks for the stories assigned to me in a given sprint
  2. As a project team member, I want to be able to track time worked and time remaining for my tasks in a given sprint
  3. As a project manager, I want to be able to view progress for all tasks and all team members in a given sprint.

From a SharePoint standpoint, these stories all require information from at least four different lists: Sprints, Product Backlog, Sprint Backlog, and Sprint Task Times. Even with lookup columns, referencing data from two lists in order to create and update data in two other lists is not something SharePoint does well out of the box. So we created a Host Web App that provides an SPA solution that covers these stories.

Here’s a screenshot of the application followed by a few notes:

ThreeWill's Task & Time Entry application

ThreeWill’s Task & Time Entry application

Each control in the application is populated by data from the Host Web, most of it from SharePoint lists. The two grids on the right also allow creating, editing, and deleting list items. The Task & Time Entry app is not much more than a mash-up of data from the Host Web that extends SharePoint to give the stories mentioned above a user experience that SharePoint doesn’t handle well OotB. As I suggested in the Where-They-Fit Checklist in my previous post, this is the sweet spot for App Web Apps, and I think the same holds for Host Web Apps.

Code Release Disclaimer
Unlike the Absence & Vacation Request app, which was written as a technology demonstration for the community, the Task & Time Entry app was written for ThreeWill’s internal use, so I can’t share the full codebase with you. However, I do have a number of concept demonstrations from the app that I can share. I expect those to show up in future blogs, but if you have specific topics you’d like to see the code for, just ping me in the comments or tweet at me (@seansageek), and I’ll get you as much as I can ASAP.

What’s Good Now?
Most of the good things App Web Apps bought us are in still in full force for Host Web Apps, so I won’t rehash them here. In addition, Host Web Apps solve a couple of problems I had with App Web Apps:

  1. No Data Silo. Now the underlying objects your app is working with live in the Host Web. The Original Web. The *Main* Web. Full access to the SharePoint collaboration toolset has been restored, and your app can be deleted independently of the data.
  2. Improved *Data* Security. Your security scheme isn’t flat, full-control for everyone. Any SharePoint lists your app uses (or creates) can have all the granular security control that we’re used to, and it’s managed from the Host Web in the same ways we’re used to.

What’s Bad Now?
I could *almost* be a fan of Host Web Apps…if the differences stopped there. Unfortunately, moving the app data to the Host Web introduces some fresh issues:

  1. Poor Schema Control Options. As I pointed out in my block diagram, there’s no declarative way to manage schema objects in the Host Web. There’s also no “install event” for hooking in programmatic schema changes. The only way Host Web Apps can directly manage objects (lists, fields, security groups, etc.) is via JavaScript executed somewhere in the app’s runtime. That means you’ve got to do something like one of the following:
    1. Create some clever (read: difficult to write and maintain) sync logic. This would periodically monitor the Host Web and apply schema and security changes *automagically* behind the scenes. Within the context of a user running the application. And oh, by the way, that user also needs to just happen to have sufficient permissions to perform that activity.
    2. Create a dedicated admin user experience in the app. This would allow site admins to run setup and/or periodic synchronization logic. Just keep your fingers crossed that they remember to do it when they’re supposed to.
    3. Manage schema changes out-of-band. This is the route we chose. The Task & Time Entry app is only supported for sites that were created using a specific template. This means we have to make sure the app logic and site template stay in sync, and educate users not to make breaking changes to the lists the app needs.
  2. Reduced Host Security. Recall (or review) the permission demand comparison above. The worst an App Web App can do in the hands of a site admin who’s careless or using a compromised browser is shoot itself in the foot or perhaps leak the site title and site user’s names and emails to evildoers. That’s not great, but the damage is largely contained within the app itself. Not so for the Host Web App. A maliciously written or compromised (read: hacked) app could delete all your site collections or syphon off data or both. A prudent admin will investigate all Host Web Apps thoroughly *before* they touch the App Catalog.
  3. More Fragile Integration. This was the biggest source of disappointment in my Host Web App experience. Allow me to demonstrate the most egregious (of several) scars in the code:
    class SPListExecutor
      constructor: (@options) -&amp;amp;amp;amp;amp;amp;amp;gt;
        @listName = @options.listName
        @appUrl = window.location.getVar(&amp;amp;amp;amp;amp;amp;quot;SPAppWebUrl&amp;amp;amp;amp;amp;amp;quot;) or &amp;amp;amp;amp;amp;amp;quot;local://appweb.local&amp;amp;amp;amp;amp;amp;quot;
        @hostUrl = window.location.getVar(&amp;amp;amp;amp;amp;amp;quot;SPHostUrl&amp;amp;amp;amp;amp;amp;quot;) or &amp;amp;amp;amp;amp;amp;quot;local://hostweb.local&amp;amp;amp;amp;amp;amp;quot;
        if @appUrl.indexOf(&amp;amp;amp;amp;amp;amp;quot;#&amp;amp;amp;amp;amp;amp;quot;) &amp;amp;amp;amp;amp;amp;amp;gt; 1 then @appUrl = @appUrl.split(&amp;amp;amp;amp;amp;amp;quot;#&amp;amp;amp;amp;amp;amp;quot;)[0]
        if @hostUrl.indexOf(&amp;amp;amp;amp;amp;amp;quot;#&amp;amp;amp;amp;amp;amp;quot;) &amp;amp;amp;amp;amp;amp;amp;gt; 1 then @hostUrl = @hostUrl.split(&amp;amp;amp;amp;amp;amp;quot;#&amp;amp;amp;amp;amp;amp;quot;)[0]
        @odataUrl = &amp;amp;amp;amp;amp;amp;quot;#{@appUrl}/_api/SP.AppContextSite(@target)/web/lists/getbytitle('#{@listName}')/&amp;amp;amp;amp;amp;amp;quot;
        @executor = new SP.RequestExecutor @appUrl.toLowerCase()

    Here’s the constructor for the SPListExecutor class in the Task & Time Entry app. If it looks disorienting, that’s probably because it’s in CoffeeScript. If you’re not familiar, just try to roll with it for now. I want to point out line 10, where the SP.RequestExecutor (remember him?) gets instantiated. Notice the “.toLowerCase()” call on the URL? That wasn’t always there. The app worked fine without it for months, but in late February *everything* in the app stopped working. After 9 days of working with Office 365 support, they finally recommended lowercasing the URL. And it worked.

    To say this another way:

    This app experienced 9 days of downtime due to a breaking change in the SP.RequestExecutor API…concerning case-sensitivity in a URL.

    Let me be extra clear: during the downtime, the REST service was working fine. The CSOM API was working fine. But JSOM and REST from the browser were hamstrung because of this error in a JavaScript library and/or the ASPX page that it consumes behind the scenes. Again, this wasn’t the only example of downtime due to fragility on the SharePoint side, just the most frustrating.

    Here’s how I’d summarize these experiences (so far):

    The REST endpoints and CSOM API to Office 365 have proven themselves to be extremely stable; The JavaScript libraries and other artifacts in the SharePoint “UI” have not. And of those, SP.RequestExecutor, has been the most fragile.

    I’m sure this will improve over time, but in the near future I have to caution you to reconsider writing any solution as a SharePoint-Hosted App, and especially as a Host Web App, if the app requires high availability.

Where Host Web Apps Fit
As with the pros and cons, Host Web Apps share most of the recommendation checklist with App Web Apps. Following are the deltas from the previous post:

  1. Are You Okay with A Flat and Open Security Structure? As long as you don’t mind completely piggybacking on the Host Web’s existing security, this issue disappears. If you need something specific to your app, then you’ll need to navigate the “schema control issues” mentioned above.
  2. Are You Okay With Silo-ed Data? Host Web Apps solve this issue convincingly.
  3. Are You Okay With (Extra) Reduced Availability ( 365-specific)? I can’t recommend betting on the availability of any SharePoint-Hosted App, but as covered above, Host Web Apps are even less stable than App Web Apps from my experience.
  4. Are You Okay With Reduced Host Web Security? If you or your organization is writing the app, and you’ve got good security controls in place, then this might be only a minor issue. But if you’re working with external vendors, or your admins spend lot of time on nefarious sites, this might cause more concern.

Pro Tips
Most of the pro tips carry over from App Web Apps post, but let me offer one new and one reiterated tip:

  1. Honor the PoLP. Host Web App permissions are a great time to reacquaint yourself with the Principle of Least Privilege. Your app should ask for the absolute minimum permissions required to perform. If you only need access to one list, use the List scope. If you only need read access, use the Read permission.
  2. Consider ShareCoffee. Again. The ShareCoffee team has covered the ugliness of working with SP.RequestExecutor in a clean, easy-to-use wrapper:
    var executor = new SP.RequestExecutor(ShareCoffee.Commons.getAppWebUrl());
    executor.executeAsync({url:&amp;amp;amp;amp;amp;amp;quot;web/lists?$select=Title,Id&amp;amp;amp;amp;amp;amp;quot;, onSuccess: onListsLoaded, onError: onError}));

    Sure, it’s not as clean as working with a standard REST endpoint, but this is *as clean as it gets*.

Next Up: Provider Hosted Apps
If you’ve read or skimmed this and the previous post—and if I’ve sounded convincing—you might be getting the same vibe from SharePoint-Hosted apps that Gertrude Stein got revisiting her childhood home in Oakland. Luckily there is another 2013 App Model option, one that requires an additional resource, but with significantly more gravitas: Provider-Hosted Apps. Tune in for the next post to find out why I think they’re worth the trouble for the majority of business solutions.

Questions? Comments? Accusations? Leave me a comment or tweet at me (@seansageek). But fair warning: if I smell tar or chicken feathers, I may run.


  1. “Service” is a bit strong: it’s actually an ASPX page.
  2. We use Scrum both internally and externally.
read more
Sean HesterSharePoint 2013 App Models Considered – Part 3

SharePoint 2013 App Models Considered – Part 2

Sean is a senior consultant at ThreeWill. He has over 16 years of experience developing web applications. His primary passions are in usability, group collaboration, project and process automation, data visualization, and social media tools. He is an MCSD in Web Applications and an MCTS in SharePoint Application Development.

In my previous post I introduced my series on SharePoint 2013 App Model Considerations, laid out the roadmap and approach for the subsequent posts, and explained why SharePoint has been the platypus of the Microsoft middleware stack. In this post, I’ll review the first App Model option: “App Web” Apps. There’s a lot of content here, so I’ve chunked it up and structured it with lists and bullets to improve skim-ability. If that’s your mindset going in (no judgment), here’s a mini-Table of contents to help you track down the right content:

  1. App Web Apps Overview
  2. Real World App Web Reference App
  3. What’s Good About App Web Apps
  4. What’s Bad About App Web Apps
  5. Where App Web Apps Fit
  6. Pro Tips for App Web Apps
  7. Notes

Running Down App Web Apps
“App Web” Apps isn’t an official Microsoft term, but it’s gaining momentum in the community as a way to describe SharePoint-Hosted Apps (that *is* an official term) that keep their data in the App Web. For the uninitiated, the App Web is a SharePoint Web that is created to host the app when the app is installed in a site collection. It’s a stripped-down SharePoint site that provides provisioning and runtime isolation for the app, and it’s the place where all the app artifacts are deployed except for two minor exceptions. Here’s a quick-n-dirty block diagram of an App Web App package, where its contents are deployed, and where its API calls are routed at runtime:

App Web App Block Diagram

App Web App Block Diagram

  1. The App can deploy several artifact types into the App Web: a reduced subset of CAML for custom SharePoint lists, fields, etc. as well as web artifacts such as HTML or ASPX pages, JavaScript files, and CSS.
  2. The App can deploy a couple of artifact types to the Host Web: App Parts and Custom Actions. As far as I’ve investigated, these are the only two artifact types that can be deployed to the Host Web. That’s an important limitation and distinction between App Web Apps and Host Web Apps.
  3. The App’s logic (JavaScript) interacts with the “local” web domain API (via REST or JSOM) for accessing and creating data, no cross-domain headaches incurred.

This is as simple as it gets for the SharePoint 2013 App Model. Everything deploys and runs in the same domain. The structure of the project looks familiar to what SharePoint developers are used to, minus the server code. The logical structure is basically a fat client architecture in a web browser. Easy peasy lemon squeezey.

“So…About This ‘Real World’ App You Mentioned?”
We re-worked the classic Fab 40 Absence & Vacation Request application as a technology demonstration of a SharePoint-Hosted App. You can see a video demo, get details, and even grab the full code for the app here. But you might want to read the rest of this post before you turn the app loose within your organization. Like its Fab 40 predecessors, it has steep edges and very few handrails. Here are a few screenshots to give you a quick start on the app’s business domain and features:


As you can see, the Absence & Vacation Request application covers a few of the most common use cases an organization might need to track group holidays and individual vacations. Now let’s look at the pros and cons of the architecture.

What’s Good Here?
Despite the gloomy pronouncement about SharePoint-Hosted app variations in my previous post, there are a number of good things happening here:

  1. It’s cloud-friendly. It won’t get much friendlier than this.
  2. It doesn’t require invasive permissions. The logic is self-contained, so SharePoint won’t prompt the site admins for invasive permissions at install time.
  3. It’s simple in several good ways.
    1. The basic CRUD happens with SharePoint’s OotB API.
    2. We’re able to make our magic happen with only one real tier of custom logic.
    3. It happens within one environment (SharePoint), and all in the scope of one web domain (our App Web).
  4. It owns its runtime logic. We have full control of everything between the HTML tags, using only the SharePoint libraries required for JSOM.
  5. It owns its user experience. We crafted a responsive user experience using Bootstrap , and in my opinion, you come out well ahead of SharePoint’s OotB UX. Don’t take my word for it–compare the Absence & Vacation Request calendar home screen to a standard SharePoint 2013 calendar1 for yourself:
  6. Goodbye, Platypus. The custom code may be confined to the presentation tier, but inside that tier you’ve got full control over your technology stack and toolset. And in case you haven’t figured it out yet, getting off the platypus is a high value improvement in my book.

What’s Bad
Unfortunately, the downsides to this approach are serious enough that they severely limit the viability of App Web Apps:

  1. No Middle Tier. It’s kinda like digressing to the client-server anti-pattern…but now you don’t control the server, either.
  2. No Private Logic or Data. If you’ve only ever developed traditional ASP.NET/MVC or SharePoint Farm Solutions, you’ve been “spoiled” by easy access to private logic and data. In App Web App world, you’ve got neither.
  3. Not “Tamper Resistant” (Read: “No Security Story”). As if it weren’t bad enough that you have no private logic, you don’t even have tamper resistant logic. Consider the following chunk of code from the Absence and Vacation Request App:
    function isAVRManager() {
     console.log("checking user's memberships.");
     //var dfd = $.Deferred(function () {
     //iterate through users in groups
     var groupCount = userGroups.get_count();
     var isManager = false;
     //loop through all of this user's groups
     for (var i = 0; i < groupCount; i++) {
     //Check for existence in Managers
     if (userGroups.getItemAtIndex(i).get_title() === 'AVR Managers') {
     isManager = true;
     console.log("User is an AVR Manager.");
     return isManager;

    The isAVRManager() function loops through the current user’s group membership via JSOM, and if they have membership in the AVR Managers group, it returns true. This unlocks all the manager-specific features I pointed out in app’s screenshots above. It’s well meaning enough on paper, but it’s so easy to unravel:

    Absence & Vacation Request - Hacked!

    Absence & Vacation Request – Hacked!

    1. Using Chrome’s Dev Tools anyone can get access to the running source of the application. In this case, all of the application logic runs from the app.js file.
    2. Here’s where the app calls the isAVRManager() function.
    3. Once that line has executed, I drop into the JavaScript console and manually set the isManager variable to true.

    The bottom line: a mildly clever and malicious user can approve their own vacation requests, or anybody else’s, or create holidays. In my book, that’s a HUGE problem.

  4. Fragile Integration. SharePoint has always been a bit of a volatile product to customize. Take that volatility, and move it to javascript running in a user’s browser, and you get the picture.
  5. Reduced Productivity. Writing your *entire* app in JavaScript presents serious productivity challenges for even seasoned JavaScript developers.
  6. Design Limitations. Kiss all your favorite .NET framework libraries and products goodbye.
  7. Silo-ed Data. You’re creating a separate SharePoint web that acts as a container for your entire app, which isolates it in ways the Farm Solutions we’re used to do not.

Where App Web Apps Fit
Given the limitations I’ve experienced working with App Web Apps, I have to recommend treating them with extreme suspicion. Following is a checklist of questions; if you can’t confidently answer “Yes” to each of them, an App Web App is probably not the right choice for you.

  1. Are All Your Use Cases Strictly UX Related? If your app needs to do more than reformat, repurpose, or extend the SharePoint OotB user experience, then an App Web App will be in over its head.
  2. Are You Okay with 100% Code Transparency? If you need privacy for your code for security, intellectual property, or other reasons, this is not the solution architecture you’re looking for.
  3. Are You Okay with a Flat and Open Security Structure? If you have any need to for multiple tiers of user privileges, you can’t get there from here (see my point about tamper resistance above).
  4. Are You Okay With a Simple Data Structure? You’ve got one real data storage option for App Web Apps: the SharePoint lists you provision to the site, and SharePoint lists have important limitations (example: item count).
  5. Are You Okay With Reduced Availability ( 365-specific)? So far this year we’ve experienced 10 days of downtime for apps caused by updates to our * tenant, caused by a combination of changes to SharePoint JavaScript libraries, and the server code that support them. ‘Nuff said.
  6. Are You Okay With Silo-ed Data? If there will *never* be a compelling need for end-user collaboration with your data, you’re golden. From my experience SharePoint users really like the collaboration tools, so I’d be skittish about starting down this path.

Pro Tips
So you’ve read and understood the warnings, you’ve reviewed the checklist above, and you still want to choose an App Web App. If you head down that road, here are a few suggestions that may make life better for you:

  1. Don’t Fake The Funk On A Nasty Dunk.You just read where I think App Web Apps make sense, right? My top tip is to keep your app in that box. Above all else, don’t try to cruft up fake security–it’s bad mojo.
  2. Keep Requirements Manageable. You’re in a reduced-capability environment. Your product requirements need to reflect that, especially early in your release cycle.
  3. Beef Up Your JavaScript Toolkit. JavaScript isn’t the most developer-friendly language, especially if you’re accustomed to compiled languages. Life will be better if your workbench includes tools and process that maximize design-time productivity and minimize reliance on runtime testing. I use and endorse all of the following:
    1. The Super-Amazing-Must-Have Web Essentials extension for Visual Studio
    2. CoffeeScript if you’re JavaScript savvy and like tight, functional logic or…
    3. TypeScript if you’re C#-oriented and crave design-time type checking
    4. JSHint to keep your code squarely in The Good Parts.
  4. Test Locally With Mock Data. If your dev process requires a SharePoint deployment–especially a deployment–to test any changes, you’re doing it WRONG! It will kill your development velocity. At a minimum, grab some sample REST query results and stuff them into a JSON file as mocks for dev and testing.
  5. Use Community Libraries. Don’t re-invent the wheel—this is no time for NIH syndrome. I use and endorse all of the following:
    1. Backbone or Angular. Pick one or the other—they’ll both jumpstart the structure and core service of your app
    2. ShareCoffee for REST and other client API helps. NOTE: ShareCoffee does not require CoffeeScript
    3. Breeze for data access, along with Andrew Connell’s Breeze SharePoint SPA code samples and patterns
    4. Bootstrap to get your CSS rolling quickly
  6. Constrain Your Consumption of SharePoint UX Assets. SharePoint’s REST and C/JSOM endpoints have been up every time I’ve tested, breaking changes to the SP.* libraries have been the largest source of downtime so far.
    1. Determine how you need to call the API–REST, JSOM, or a mix–and get that code stable as early as possible.
    2. Minimize the number of SharePoint JavaScript references. Somewhere between zero and three is the right answer, depending on your answer above.
    3. Keep your API call logic in one place. If possible, have a JavaScript class (or two) dedicated to it.
  7. Familiarize Yourself With SharePoint’s REST API. This is one of those cases where an hour or two of reading will pay off with big dividends. Here are some MSDN resources I recommend:
    1. Apps for SharePoint REST API Reference
    2. How to: Complete basic operations using SharePoint 2013 REST endpoints
    3. Working with lists and list items with REST

Next Up: Host Web Apps
Phew! Did you make it all the way through? If you skimmed through, I hope you found the list structure helpful. If you haven’t had enough abuse yet, in my next post I’ll examine the Host Web App as an architectural option. Spoiler alert: it improves on App Web Apps in one key area, but introduces some new issues. In the meantime, if you have questions or comments about the troubles I’ve seen, the conclusions I’ve drawn, or the code we’ve shared, leave me a comment or tweet at me (@seansageek)–I’d be happy to discuss it with you .

1: The standard SharePoint calendar screenshots are from a standard Calendar App in circa June 2014. The Mobile Browser View feature was enabled.

read more
Sean HesterSharePoint 2013 App Models Considered – Part 2

SharePoint 2013 App Models Considered – Part 1

Sean is a senior consultant at ThreeWill. He has over 16 years of experience developing web applications. His primary passions are in usability, group collaboration, project and process automation, data visualization, and social media tools. He is an MCSD in Web Applications and an MCTS in SharePoint Application Development.

Over the last year, one of the hottest topics of discussion at ThreeWill has been the new SharePoint 2013 App Models; and specifically where each model might make the most sense given a particular solution requirement. Choosing an App Model is a critical decision for your solution, and as I worked with each of them, I hit a number of gotchas with their architecture that weren’t obvious at the project outset. These gotchas happened despite the effort I put into researching them in SharePoint blogosphere.

My top takeaway from the experience so far is simple but provocative:

The number of “real world” business cases where SharePoint-Hosted App Model variations make sense is very small; most solutions are going to require a Provider-Hosted app.

You can find a number of big names in the SharePoint community—people I have tremendous respect for—who’ll disagree with that statement. I don’t like offering unsubstantiated opinions, so over the next few blog posts I’m going to share my experiences developing apps for SharePoint 2013, across three App Model variations.

Here’s the roadmap for the series:

  1. Part 1: Introduction, a.k.a. “This Post”. A high-level introduction to SharePoint 2013 App Model considerations with some thoughts on why we’re here and a word of encouragement.
  2. Part 2: App Web Hosted Apps. My thoughts on SharePoint-Hosted Apps with app data stored in the web, and where the app deploys to and runs in.
  3. Part 3: Host Web Hosted Apps. My thoughts on SharePoint-Hosted Apps with data stored in the web that activates/installs the app. The differences between Host Web and App Web may seem subtle, but a couple of the distinctions are critically important.
  4. Part 4: Provider-Hosted Apps. Apps where the primary logic and runtime are in an application external to the SharePoint site. Bringing secondary environments to your solution has complications, but it offers tremendous power.
  5. Part 5: Observations and Conclusions. I’ll wrap up the series by offering a high-level comparison of each app model across some common application features, requirements, and concerns. I’ll also provide a matrix you’ll be able to adopt and modify for making App Model architecture choices in your own apps.

Note that the three App Models I’ll investigate in this series are not a comprehensive list. There’s plenty of room for variation and nuance, and in all likelihood hybrids (in multiple senses of the word) will be the most common solutions. But the three architectures I’ll feature are certainly representative of the SharePoint 2013 App Models, and they cover two of the most basic decisions you’ll need to make for any App Model-based solution:

  1. In SharePoint, where will the data for my app live: in the App Web or in the Host Web?
  2. Am I going to need to use an external provider? If you start without one, I’m betting you’ll want one before release 1.1.

As I cover each App Model, I’ll provide code in one format or another from a real app that I’ve worked on. I’ll offer my thoughts on the strengths and weaknesses of each model. I’ll also provide “pro tips” (I’ll allege that they’re pro tips) based on my experiences and battle scars.

But First, Some Background
Before we dig into the specifics of each model, I want to set the table. We’re standing at the most significant inflection point in SharePoint’s product history for a handful of converging reasons. The most obvious is SharePoint needed a plausible story for cloud-hosted custom development. Sandbox solutions didn’t inspire tremendous adoption in the industry, and even in their unappealing state they relied too heavily on the server to be truly Office 365 friendly. In contrast, both SharePoint-Hosted and Provider-Hosted solutions completely remove custom code from the SharePoint server while still offering an effective presence and broad support for customizations. If the primary goal of the SharePoint 2013 App Models was to provide cloud-friendly customization routes for SharePoint, mission accomplished. They’re not without limitations and corners, but overall they’re a success.

From my perspective, the new App Models pursue a more intriguing secondary goal. When I’m feeling cheeky I sum it up like this:

Pre-2013 SharePoint was the platypus of the Microsoft middleware stack, and in desperate need of an evolutionary reboot.

SharePoint Is A Platypus
Pre-2013, SharePoint had been stuck in a strange evolutionary backwater. It’s architecture was still firmly rooted in concepts from ASP.NET version 1 and 2: Web Forms, Web Parts, Server Controls, etc. Concepts more than a decade old at this point, and to me they feel even older than that. And though Pre-2013 SharePoint may be highly adapted to certain environments, there are steep capability edges if you need to grow beyond its natural habitat.

Outside of this backwater, the rest of the Microsoft web development world has enjoyed amazing progress courtesy of the ASP.NET and .NET framework teams. The advances I miss most when writing pre-2013 (i.e. Farm) Solutions are:

  2. Entity Framework
  3. Visual Studio Test Automation
  4. Single-Page App Frameworks like Angular and Backbone
  5. HTML5
  6. Web API 2

In short, the web development world has been passing SharePoint by. To illustrate how large the gaps are, I’ve worked up a timeline comparing SharePoint’s product release cycle with major milestones in web development tooling:

SharePoint App Dev Timeline

SharePoint App Dev Timeline

The kicker is that these advances aren’t just available; they represent the prescribed best practices for the web development community at large. We might disagree about the impact of these developments, or how workable the workarounds are, but I can make a strong case that SharePoint has been perpetually riding the tail of web development technology curve, and that story wasn’t going to improve much without drastic intervention.

The good news is that the SharePoint 2013 App Models are that drastic intervention: they’re an end-run around the platypus’ limitations. Even within the constraints of an App Web Hosted solution, the choice of UX tools and frameworks feels liberating compared to the nip-tuck approaches to client-side development for Farm Solutions. And with a Provider Hosted architecture, you’ve got complete access to the latest versions of your preferred development stack and community tools. You’ll run out of time to research your options well before you run out of options.

Don’t Panic
If you’ve stuck with me this far, let me offer you one last word of encouragement: Don’t Panic. Almost always good advice, but now it’s particularly apt for the seasoned SharePoint developer who’s been paying bills by writing custom features, web parts, app pages and server controls for for the past 3+ years. You know – those of us who’ve been riding the Platypus. We’re all having a serious who-moved-my-cheese moment over SharePoint 2013, but in the long run, I think our lives will improve as the new App Model adoption rates climb. Yes, we’ll have to invest time learning new tools and development patterns. But those tools and patterns are going to make us more productive, align our skills more closely with the larger web development community, and offer us opportunities to extend the reach and value of our solutions.

Good times.

Next Up: App Web Hosted Apps
In my next post, I’ll take a deep dive into my experience working with App Web Hosted Apps, and try to explain where I think they make the most sense. Spoiler alert: it may be User Experience related.

1: TL;DR is geek shorthand for “Too Long; Didn’t Read”. It’s used either derisively by commenters as a response to an over-long post, or pre-emptively by authors to indicate a quick summary of an over-long post.

read more
Sean HesterSharePoint 2013 App Models Considered – Part 1

New Webinar – Choosing a SharePoint App Model Architecture Webinar

John Underwood is a Technical Evangelist at ThreeWill. He has nearly thirty years of software development experience. He is an experienced technical instructor with superior presentation skills and is proficient in delivering standard curriculum as well as developing and delivering custom curriculum.

Choosing a SharePoint App Model Architecture Webinar

SharePoint Hosted? Provider Hosted? What do these mean, and beyond that, which one is right for your app? In this webinar we’ll look at the choices and draw some conclusions on the proper usage of these different architectures. Learn what you need to make a good decision about choosing a SharePoint App Model architecture.


Software architects, developers, and business stakeholders that are investing in SharePoint Apps.

Apps for SharePoint Hosting Options

The SharePoint 2013 app model provides the following ways to host the components of an app for SharePoint:

  • Provider-hosted: Apps that include at least one remote component and may also include SharePoint components. The non-SharePoint components are deployed by your logic on your hardware or cloud account, or deployed on the customer’s hardware or cloud account using installation programs and instructions that you provide.
  • SharePoint-hosted: Apps that include only SharePoint components and logic that runs on the client.


Register Now
read more
John UnderwoodNew Webinar – Choosing a SharePoint App Model Architecture Webinar

Client Side Validation for SharePoint Provider Hosted Apps

Eric Bowden has over 19 years of software development experience around enterprise and departmental business productivity applications.


As a refresher, client-side validation is form validation that occurs in web forms, purely client-side, prior to any over-the-wire activity such as attempting to post the form. There are two ways to present client-side form validation errors to the user: as a Validation Summary (a bulleted list of all form validation errors) and as individual form validation errors next to each corresponding input field.

The screen snap below illustrates how form validation may appear. The messages in the top of the form are the Validation Summary and is placed in the MVC view using the tag @Html.ValidationSummary().


The validation summary shown above appears because of entity model attributes which decorate the model object, RegisterModel in this example, which is backing the view.

Notice the attributes Required, EmailAddress, StringLength, and Compare which decorate the properties of the RegisterViewModel shown below.


Adding support for Entity Framework 6 to a SharePoint provider hosted app isn’t too difficult and is fairly well documented.  You’ll want to start by adding the NUGET package EntityFramework and follow along with a tutorial such as Getting Started with EF 6 using MVC 5 : The Official Microsoft ASP.NET Site.

Client Side Validation for SharePoint Provider Hosted Apps

All was well for me, until I needed to enable client-side validation.  I struggled with this for a bit and didn’t find the steps to be documented or discussed elsewhere, so I thought I’d share with you the trick.

First, use NUGET to install the following packages, in this order:

  • jQuery Validation
  • Microsoft jQuery Unobtrusive Validation

Reverse the order, and you’ll see the following error message:  Updating ‘jQuery 1.10.2’ to ‘jQuery 1.4.1’ failed. Unable to find a version of ‘Microsoft.jQuery.Unobtrusive.Validation’ that is compatible with ‘jQuery 1.4.1.’ Naturally, this error message led me down the path of trying to upgrade or downgrade my version of jQuery – a rabbit hole that led me into the depths of nuget that I didn’t want to see and which took some time to recover!  But the remedy is very simple; install the nuget packages in the order shown above.

Next, add the following line to your bundleconfig.cs:

bundles.Add(new ScriptBundle("~/bundles/jqueryval").Include("~/Scripts/jquery.validate*"));

Last, add the following to the bottom of the view in which you need to enable client-side validation:

@section Scripts {

In a discussion last week (Convert MVC application to SharePoint 2013 provider hosted app | Bas Lijten), Bo George discovered at least one concrete reason to create an MVC 5 first and then convert it to a SharePoint app.  It looks like this may be another one.  I used an MVC 5 project template to debug this issue and ultimately discovered why client side validation would not work for me in my SharePoint provider hosted app.

From now on, I’ll know to open up a stand-alone MVC 5 app as a first step when debugging features created using SharePoint app template.

read more
Eric BowdenClient Side Validation for SharePoint Provider Hosted Apps