Full trust computing. That was the plan under Microsoft’s old application development model. But now, with all the moves Microsoft has made to jumpstart business, the question has become: Can developers trust Microsoft?
“The SharePoint Cowboy” Eric Shupps is a Microsoft MVP whose company, BinaryWave, delivers products and consulting to users of SharePoint Server on-premise. He sees customers worried that the sand beneath their feet is shifting.
“We told people in 2010, ‘Use the Sandbox first, and go for full trust second.’ Today, it’s ‘Apps first, then full trust only if you must,’ ” Shupps said. “Developers wonder, ‘Is this going to go the way of the sandbox? Will it only last one revision, when I know the full trust environment will last?’ ”
In his SharePoint Cowboy blog, Shupps wrote:
“So what does this all mean for developers? Should you continue to invest in full-trust, on-premise solutions, or move to the new app model? The answer, of course, is ‘It depends.’ It all comes down to your requirements—there are some scenarios where apps are the right answer and others where full-trust solutions will be more appropriate. But let’s be clear about one thing: Isolated code execution via remote interfaces is the future of SharePoint development. Period. That doesn’t mean you need to throw out all your existing code and start over from scratch, but it does mean that you need to start thinking about, and planning for, a new way of doing things. Getting a head start on it now will pay dividends in the long run, so there’s no reason to delay. If you’re not yet familiar with building SharePoint apps, then now would be a good time to get started.”
Perhaps a larger question, though, is how much of what developers build has to be in SharePoint? “In Office 365, it’s only apps. It’s time for developers to get educated on that,” Shupps said. “If you understand REST and OAuth, you’ll have a comfort factor.”
Again, he wrote:
“Before you sign off on the final design spec for another big batch of server-side code, though, stop and ask yourself this question: How much of the code actually has to be in SharePoint? After more than a decade writing custom solutions for SharePoint, I’ve found that less than 20% of the code I’ve written actually uses the SharePoint APIs. The vast majority of it is just standard .NET components and classes. Sure, there have been a few SharePoint-centric solutions that have required deep integration with the dark inner workings of the platform, but by and large that’s not the case.