Saturday, August 13, 2011

Office 365 development

I am a bit excited about office 365.

My company (Extelligent Design) is now a 365 partner, and we aim to support clients implementing it. We want to help people set it up, understand how to use it (my book may come in handy, seeing as the end user interface to the sharepoint online is the same as regular sharepoint) and customise it.

Customising is where the real challange begins. As you probably know, to develop for office 365, you can only use the sandbox - which limits what you can achieve in your customisations. I find that not being able to install application pages (pages that go to the _layouts folder) especially frustrating, and, like a fish out of the water for the first time in its life, I suddenly realise how much I tend to rely on having that resource.

Ok, maybe the fish analogy is a bit much. I can still write web parts, and features with event receivers - not to mention list and library event receivers as well! But this is when I hit another wall - a lot of code I wrote in the past relied on me being able to run sections of the code with elevated privilages. This is gone if you develop a sandbox solution, and is very frustrating. Some obvious things that people will want to do in their hosted sharepoint site rely on code being able to run as other users. Workflows are a great example - having a user with permissions on list A enter data into that list, and then the workflow enters data into another list to which the user does not have permissions. Oh, wait, workflows are also not allowed in hosted sharepoint, so replace the word "workflow" with "event receiver" in the sentance above and you still get the same functionality, and you still hit a wall with not being able to write code that implements that requirement.

PS - the security limitation is blocked for both usual methods of running in elevated privilages mode - you cannot use the security namespace (preveting you from using SPSecurity.RunWithElevatedPrivilages) and you cannot use the SPSite constructore - preventing you from loading a new SPSite object with the system user's token.

So where does this leave us? Not all is doom and gloom - we can still write web parts and event handlers and features - as long as they are not too complex. This is great for deploying look and feel, features that implement site templates and more. I see a lot of developers now focusing on creating turn-key solutions that implement industry-specific templates for sites. Small businesses have a lot in common, and they are the real target of office 365 - so anyone who comes up with a feature that creates lists and libraries that solve a common problem for a small business may hit a jackpot similar to the mobile phone app developers.

Finally, hosting companies that host office 365 may let you deploy code to the servers directly, allowing non-sandbox development to take place. I think this will be hardest to do, since those companies will be very afraid to change their environment from the microsoft default, but a strong partnership with such a company may be a great thing for a sharepoint developer. Come to think of it- if you ARE a hosting company that office 365 hosting and you want some value add to your clients - talk to me!

Office 2010 SP1

Ok, this may not be a sharepoint post, but...

If you are like me, you have "Virtual Clone Drive" installed, allowing you to mount ISO files as virtual CDs (other virutal CD software is available).

If you are like me, you do not have a physical CD drive in your laptop (having pulled it out and put a second SSD in instead).

If you are like me, you are running office 2010.

If you are like me, you always install whatever Windows Update tells you to install.

So...if you are like me, then you have been unable to install service pack 1 of Office 2010, failing (of all things) on installing a sharepoint client component.

The solution turns out to be simple - disable the virtual CD drive and then do the update. Some recommendations from Microsoft also suggests to put a DVD or CD in your physical CD drive while patching. Seems to be a bug in SP1.

Lucky for us sharepoint people that the SharePoint SP1 doesnt have all these annoying installation bugs. Oh, wait...