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.

PSA: InfoPath and Office 2016

Office 2016 was just released today. I was so excited to download and install it. I have my reasons. Just ask those of you who get annoying junk mail notifications in Outlook 2013 how much you hate it. Yeah, Microsoft never fixed it.

I then started looking into how I should upgrade. Most easily done if you have an Office 365 subscription. Ok, cool. I then noticed that the InfoPath icon wasn’t included among the apps. We all know by now that InfoPath has been deprecated. I thought that maybe Microsoft would include the 2013 version with their 2016 suite, since they wouldn’t be upgrading it.

The answer is NO. If you have Office 2013 suite install with InfoPath 2013, that version of InfoPath will get wiped and removed along with your entire Office 2013 suite and upgraded to 2016. In order to create/modify InfoPath forms on Office 2016, you will need to reinstall InfoPath 2013. This will leave you with two “installations” of Office: 2016 and 2013.

Just a friendly PSA. Check here for more info.

SharePoint Irony

I do find it kind of ironic that this blog is not SharePoint hosted (no pun intended, Scott). Blame Microsoft. They can never seem to figure out what they want to do, so I guess this ended up here on WordPress.

If you would have asked me what SharePoint was 4-5 years ago, my honest answer would have been “a Microsoft product”. One two-day crash course and five clients later, I’m thankful to have been able to make a comfortable living developing in SharePoint exclusively. A lot of this is owed to great SharePoint gurus like Scott himself, who was my co-worker and is my colleague.

SharePoint is a great platform for business process automation. It is not a dumping ground for documents (but you can use it for that if you want). SharePoint can be your friend, and it can be your worst nightmare. It is what you make of it. In application, don’t think of things in a SharePoint-ey way, think of it practically. Then, learn and apply SharePoint to fit that practicality.

Oh, and one more thing Scott. It’s spelled “Tardar Sauce“.