Cloud based services are becoming more popular as more organisations recognise the costs savings that come from letting someone else manage your software and infrastructure. So what does it mean for companies wanting to deploy SharePoint in the cloud?
The pros
- Less expertise required to get up and running
- Guaranteed up times
- Less maintenance. Back ups and updates are done for you
- Add on services – Office 365 can provide a full suite of tools including LYNC (Communications Server), Hosted Exchange, Dynamics CRM
- Cheap if you have 10 or less users.
The Cons
- There is a minimal custom SharePoint Development allowed. Forget third party add-ons or customising the look and feel too much
- It won’t be as fast as an in house system. Especially when uploading and downloading documents
- You can’t integrate it with other systems you have on premises
- You need to run Federated Active Directory services so that your users can be imported into SharePoint
Conclusion
If you are a small company that just needs the built in SharePoint functions and isn’t concerned about the look and feel of their site and especially if you don’t have in house IT support then Office 365 is probably a good solution.
If you are a larger organisation who’s needs may grow to require custom functionality then we wouldn’t advise at this point. Plans start at approx. $8 per user per month and go up significantly depending on your plan so it is cheap if you only have a few users.
If you would like to discuss SharePoint Design, SharePoint Customisation or SharePoint Development call Webcoda to speak to one of our SharePoint Experts!
There are many articles on how to do SharePoint development on an XP pc. E.G http://fernandof.wordpress.com/2008/02/11/how-to-install-the-sharepoint-2007-vs-2005-extensions-on-a-workstation/
The question is does this give you the same experience as the recommended method of developing directly on a SharePoint server?
The bottom line is NO. The reason is that these methods still won't allow you to connect to a SharePoint web.
i.e Anything like this won't work
this._Web = SPContext.Current.Web; or
this._Web = new SPSite(http://<IP_ADDRESS>).OpenWeb();
In other words you can compile but to see the results you will have to deploy to a SharePoint server.
The only exception to this rule is with web parts where code doesn't actually interact with the SharePoint object model and is just a standalone web part. Then you can test your web part by creating a web project with web part zones and run your web part from there.
If that hasn't put you off here are a couple of extra steps you may need to get going with SharePoint dev on XP.
1) Copy all the DLLs out of the GAC of SharePoint install.
From http://mossofall.blogspot.com/2007/05/how-to-get-microsoftsharepoint-dlls-out.html
So, to extract these DLLs (for example in the c:\temp folder), I use a classic XCOPY command in command line from the folder C:\windows\assembly\ :
XCOPY GAC_MSIL c:\temp /
Then use a normal windows search to find all dll in temp folderabd copy out the SharePoint related ones.
Copy the DLLS to your local GAC. i.e to C:\windows\assembly
Do an IISRESET.
2) If you get a personalization web.config error when testing we parts in local web part zone enabled Site
Make sure you set personalization on your web part manager off for testing locally
<asp:WebPartManager ID="uiWPManager" runat="server" Personalization-Enabled="false"></asp:WebPartManager>