There’s a lot of buzz nowadays about moving to Office 365 and using the App Model to extend and customize the platform. However, I know a lot of folks aren’t even considering Office 365 just yet, so I was wondering how are you developing “Apps” internally?
Are you using Full Trust Farm solutions? Or, are you starting to create Apps internally? I am guessing the decision points will be based on the fact that Farm Solutions are far quicker to develop, but harder to migrate in the future. Whereas “Apps” are slow to develop but set you up for a potential move to Office 365…
Love to hear your thoughts…
>>Colin – fantastic response. At Collaboris, we have been struggling to put together a few “simple” templates using declarative mark-up only. Workflow has been the biggest barrier and pain point. It’s taken way too long and has cost a fortune. In the time the devs have been on that, I have managed to create and publish 3 new Workdpress sites!Â
Microsoft and PnP “officially” suggest to do a code based provision. That’s it. MVPs nowadays tell everyone how to do that, people at MS promoting that as well as promoting “remote provisioning pattern”, that’s how they call it 🙂 XML/WSP was not a good options not in 2007, not in 2010. That’s the other discussion, but simply sayin WSP/XML don’t fit a proper ALM process, have to much limitation and can hardly be tested (ALM again).Â
SP2013 workflow can be provisioned via code. An API is there, all good. SPMeta2 simplifies provisioning, as well as was able to do workflow that for quite a time, plus there are samples in various blogs.
>>We are currently re-architecting DocRead for Office 365 and it’s going to be tough, but we are taking the approach to use as little SP functionality as we can.Â
Tough! Really tough, guys. But keep it up, we will be there.
>>I totally agree with the point made by Denis in that setting up an Apps friendly environment for on-prem is simply way too painful.Â
What exactly was painful? SPAutoInstaller + some PowerShell script don’t do the job? Plus, as yo mentioned, the stable farm, easy upgrades and better ALM delivered to the client is worth other inconvenience caused. Â
>>Over and above the complexity and expense of setting up the environment we are still way too constricted in what can be done with the available OMs and the problem is we (as developers) don’t really know how constricted we are until we hit a road-block. More risk and uncertainty
Well, there is MSDN plus all assemblies are available. If we don’t know how to use it, that’s our own problem. Would it be fair that client gonna pay for instable farm cause by farm solutions due “developers” have not learn CSOM? Maybe, maybe not.Â
>>You also have to completely re-engineer things.Â
True. It might worth it, and it might now. That’s totally up to the project.
>>Finally, and I know I am a heretic here, I just cannot get over the idea that JavaScript and iFrames are the future of SharePoint development.
Have a look around, outside of the SharePoint world. Maybe Facebook does the same trick, and maybe there are some reasons for that 🙂
>>So the bottom line is that for on-prem (not 365, that’s a different story) the current cloud app model offering will do nothing for end users, will bring added uncertainty and therefore risk to projects will cause ‘real’ developers to toss and turn at night and will cost customers more. That’s a tough sell!
Why? For instance? “The current cloud app model offering will do nothing for end users” <– for instance? CSOM is there, all good 😉
>>Finally, finally how certain are we that this really is the future?Â
Yea, and this is a good future lots of folks were keen to see 🙂
>>Â A few years back the future was Silverlight
Maybe it was not the future, but temporary competitor to the Adobe AIR.
All good, let’s rock! 🙂
>>Provider hosted apps are much harder to set up because they require a lot of pre reqs
What exactly is hard? Automated install powered by SPAutoInstaller helps a lot, so SharePoint farm installation nowadays is not a big deal with the right tooling and planning in place. Not a dramatic difference. Some people fine with it, some are not – that’s fine too.
Having said that, how “apps” infra is “bad” and hard to install, please don’t avoid mentioning how “easy” is farm solutions upgrade, what is the impact on farm performance, stability maintainability an future upgrades. Somehow people “forget” about that and that are fine with “IISReset” thing ruining the farm in the middle of the day 🙂
CSOM is limited, true. It has also a positive thing – no one would go deep and ruin the farm or produce something which hard to support and migrate to the next version.Â
Sum up is simple – no farm solutions are to be done as well as no clients should ever consider farm solutions. Apps are the only way to get to the bright future according to the recent PnP, PLA (Platform Line Architectire) and nice portability across on-prem and cloud.
One more time, it is not about personal preferences anymore, but about stable farm and open way to get custom functionality work on both onprem/cloud.Â
Colin – fantastic response. At Collaboris, we have been struggling to put together a few “simple” templates using declarative mark-up only. Workflow has been the biggest barrier and pain point. It’s taken way too long and has cost a fortune. In the time the devs have been on that, I have managed to create and publish 3 new Workdpress sites!Â
However, I do feel the future will be better and I know Microsoft are definitely listening to us! Jeremy Thake was a great hire for them. He’s continuing to act like an MVP but now working for MS. It’s great to see that he’s happy to educate and also take in feedback.Â
Having said that, I think we are in for quite a few months of frustration until we finally get something that’s on par with the server OM.
Will they phase out the App Model? I think this is doubtful, Silverlight had a great alternative (HTML 5, WPF) and Sandbox Solutions had Full Trust Solutions to use. If you take the App Model away then what else is there for building on top of Office 365?
We are currently re-architecting DocRead for Office 365 and it’s going to be tough, but we are taking the approach to use as little SP functionality as we can. This way it’ll be cheaper for us to develop and maintain and also less fragile to the torrent of Office 365 changes. We are going to place most of our UI in Azure and pull in what we need via CSOM / JSOM.Â
I agree with you 100% I am finding  I start building some requirements for a client in a SharePoint hosted app and as is the way with Agile , they want to something that really is appropriate for on prem provider hosted, such as a taxonomy picker. It  all gets so much more complicated.. Rather than wrestle with the OM ,  I am considering building custom pages – maybe getting apps to provision them whilst the guidance matures 😉
