Lessons: Developing a SharePoint app for a high trust environment

I just went through the harrowing experience of developing a SharePoint app for a high trust environment. Some of it was due to office politics, while most was due to plain miscommunication and incompetence.

There are some important lessons to be garnered which I think apply to any instance in which you are contemplating developing an app for your environment.

  1. High trust apps cannot be “ported” to cloud solutions, such as SharePoint Online or Office 365. If you code your app correctly, you can reuse the code and the overall framework of your app. For instance, I coded my app using the Client Side Object Model (CSOM), which is one of the recommended languages that Microsoft wants you to use when building an app; therefore I can reuse my code should my client want to move to the cloud in the future.
  2. If you are going to be developing a high trust application, you need to make absolutely certain that your infrastructure is appropriately configured. This is way too much of a topic to cover as it is expansive, and I don’t say that lightly. It doesn’t help that Microsoft’s own documentation is lacking and in some cases just wrong (I’m looking at you, MSDN Powershell code). If your environment is not configured properly, you will be fighting an uphill battle with an almost infinite number of possible moving factors which might cause your app to fail.
  3. Consider the return on investment (ROI). If you can accomplish the same end goal building a traditional, farm based solution, I would advise you go with the latter and not the former just because it’s newer and shinier. Chances are if you are building an app in a high trust environment, like I was with my client, there is no chance you are going to the cloud anytime in the near future, irrespective of what the Microsoft talking heads are telling you. Plan and build accordingly. Be smart about the choices you make when contemplating the SharePoint app model versus a traditional solution.
  4. LISTEN TO YOUR INFRASTRUCTURE PEOPLE. Just because other developers on the ground happen to be Microsoft, this doesn’t mean they are the best equipped to be giving you input on the solution you are building. Your app will only be as successful as the actual configuration of the environment you are deploying on. Make sure you get all the appropriate certificate serial numbers, issuer IDs, and token information necessary for your app from the infrastructure folks.

With SharePoint 2013, there are some quirks which just cannot be overcome with a standard, traditional farm solution, irrespective of the code you write. In this case, you will have no choice but to write your app using the app model. I had this misfortune particularly with the site collection provisioning process, which at a certain step could not be overridden no matter what using a traditional farm solution, but that is a topic for another time.

What is high trust? High trust is basically the same concept as with a traditional farm solution, in which your app will have “superpowers” to the farm, and therefore can have the same ramifications as a traditional solution if something were to go wrong. Where it deviates is the fact that you can build your app so that it is hosted completely outside of SharePoint, therefore isolating and preventing it from screwing with your SharePoint instance. Therefore, your app can go “down”, and will not take SharePoint with it.

This topic can go on and on, but that is it for now. I’ll have much more to share in the near future.