I was wondering which is the best way to deploy our typical SharePoint artifacts such as list definitions, content types and site columns that we usually design in Visual Studio to a Office365 site collection.
I have been working on O365 for more than an year now and the only solution that I came up with is to create a sandboxed solution with no code and obviously deploy it to my site.
Unfortunately many clients nowadays don't even want to hear the word "sandboxed", so is there an alternative solution?
Thanks for the help!
The Office 365 Patterns and Practices has examples on how to do that:
https://github.com/OfficeDev/PnP
Mainly in https://github.com/OfficeDev/PnP/tree/master/Samples you will find all the items you are looking for.
https://github.com/OfficeDev/PnP/tree/master/Solutions/Provisioning.Framework.Cloud.Async contains a fully built solution with an xml based templating engine to fully provision sites/site collections.
Sandbox solutions are still very applicable, especially in O365 .CSOM with PowerShell is another viable alternative solution .This thread has discussed about this topic. Please refer to below article :
Programmatically creating Site Columns and Content Types using the App Model
Related
Previously when provisioning list, libraries, site columns, content types, list definitions etc in SharePoint I typically used SharePoint features, deployed via a WSP - or used PowerShell scripts. This meant I had a package that could be deployed to DEV / TEST / PROD.
I'm working with SharePoint within Office 365 and unsure on the best way to provision lists / libraries / features within SharePoint.
Options:
No Code Sandboxed Solutions
Trying to avoid using these as the information from Microsoft on whether they are deprecated is flaky - however sandboxed solutions would allow me to deploy features with list definitions etc. I know sandboxed solutions with c# are definitely deprecated, but the info around no code solutions is poor.
Apps
I know apps can provision at both the app and host web level, but creating lists, libraries etc using the CSOM seems like a lot of effort and a step backwards.
PowerShell
The SP Online PowerShell is nowhere near as powerful as on-prem SP. I can provision site collections through this, but not lists or libraries...
I'm keen to know how other developers are deploying to Office 365, specifically around provisioning sites with specific list definitions, libraries, content types and so on...
Thanks
Microsoft did clarify the position on No Code Sandbox solutions - http://blogs.msdn.com/b/sharepointdev/archive/2014/01/14/deprecation-of-custom-code-in-sandboxed-solutions.aspx
Also if you are looking at using Powershell to deploy then you might want to go down the route of using CSOM from within PowerShell - SharePoint Client Browser for SharePoint 2013 is good for setting up a session also very good for viewing the content of a 365 tenant - http://spcb.codeplex.com/
I have been using code based provision for almost two years without any issues at all.
Server side model works just fine, CSOM has some limitation but stil cool one and JSOM could deliver the same feature set as both CSOM and SSOM, sorta 95% :)
PowerShell is not the best option as it hard to integrate into CI, put some unit testing and regressions.
As you mentioned, this is "step back", but if only you don't have any framework or foundation for that. My libraries are internal one, but there is SPGenesis at codeplex and SPMeta2.
As community don't really care, need or with such libraries for provisioning (yep, let's face it), there are much such libraries at all, but there are lots of "MVP" samples sorta "hello world" level.
Finally, what I would suggest is to invest your time and effort in code based provision.
This is a future, that's it ;)
UPD
Struggling with SharePoint's API inconsistency, bugs, "by-design" behaviour, unaffordable amount of time to write, support and upgrade WSP packages and XML, a team of passionate SharePoint professionals decided to come up with robust, testable and repeatable way to deploy such artifacts like fields, content types, libraries, pages and many more.
Enjoy and let us know how it goes.
SPMeta2 at GitHub
SPMeta2 at Nuget
SPMeta2 Documentation Wiki
SPMeta2 Bugtracker
We have an ASP.NET website that we use internally to do some project tracking and various work. We would like to integrate some pieces of it to co-exist with Sharepoint2007 WSS.
Basically what we would really need to do is be able to add items to a list in one of the Sharepoint sites.
I'm not sure where to begin. I've looked online a bit but it seems overly complicated. Is there a quick start guide somewhere that can get me rolling with ease?
The SharePoint Web Services would be a logical place to start. In my opinion this would be the easiest way to build interaction between ASP.NET and SharePoint.
A list of available web services can be found on MSDN.
If adding items to a list is the primary goal, then check out the UpdateListItems method of the Lists web service.
With the scope narrowed to Web Services, you can certainly find tutorials/references online. However, this InfoQ post by Trent Swanson is a decent introduction to SP web services. Note that they recommend generating .NET types using XSD files; in practice, for simple projects I have simply parsed the XML myself using LINQ. You can make it as easy or complex as you like, I suppose.
We are currently in the process of drawing up a solution for an existing client, creating a number of eServices. The client currently have MOSS 2007. The proposed solution is to use MOSS as the launching pad for the eServices…
The requirement involves drawing up several online forms which provide registration facilities as well as facilitating a workflow of some sort. I have been told that the proposed solution requires complex web forms.
Most are complex forms with parent child details that have multiple windows. The proposed solution is to do some bespoke development, developing ASP .NET forms. These forms would be deployed under the _layouts folder of the current MOSS portal, inheriting the master page design on the current site.
I have been told that this approach make development and deployment more simple, as well has having ‘complete integration’ with MOSS.
My questions are:
Is this the best way to leverage SharePoint – it seems like the proposed solution is not leveraging MOSS at all..! I thought perhaps utilizing Web Parts would be better, but I have been told that this is more complex and developing more smarter intuitive UI is more difficult. Is this really the case? If not, what should be the recommended approach?
We will be utilizing Ultimus as the workflow engine. However, I have been recommended K2 Workflows. Anyone used both/have any opinions on either?
Many thanks in advance!
Kind Regards,
If they have MOSS 2007 Enterprise, you might consider if web rendered InfoPath forms can meet your needs for "complex web forms". When it comes down to it, probably all of these technologies can meet the neeed it is just a matter of what skill sets you and your customer have and how that will facilitate keeping this solution up to date.
Asim, what they propose is a possible solution. They can however provide the same functionality by making use of webparts. With the details you are giving us that isn't really possible to decide which option would be easier. I used both approaches in the same project depending on the requirements of each functionality.
I can understand that it doesn't seem like they are leveraging MOSS, but they actually are building pages within the context of MOSS.
I haven't really heard about Ultimus, I did use K2 in a proof of concept and I was quite happy with it. Then again, choosing the right workflow solution depends on your requirements.
Is it possible to move a MOSS subsite and content to a different site collection using the SharePoint API? For example, I would like to archive a subsite, by moving it from /teamsite/subsite1 to /teamsite/archive/subsite1. I am using MOSS 2007.
Thanks, MagicAndi.
MagicAndi,
The answer is a resounding "yes." The import and export of sites within SharePoint is handled through the Content Deployment API (also known as the PRIME API). This API is responsible for providing the backing to both import/export functionality supplied through STSADM.exe; it also handles the content deployment within MOSS.
A great place to get started with the Content Deployment API is with a series of articles written by Stefan Gossner. Stefan is an escalation engineer for Microsoft, and you'd be hard pressed to find someone more knowledgeable in the practical workings of the PRIME API:
http://blogs.technet.com/stefan_gossner/archive/2007/08/30/deep-dive-into-the-sharepoint-content-deployment-and-migration-api-part-1.aspx
All parts of this six-part series are excellent, and I recommend reading them all. Parts three and four, though, get to some of the specifics of the import and export operations you indicated you'd like to implement.
I hope this helps!
You need to look in to the Content Deployment API, Here is one of the Class Article in the subject.
I'm trying to create/add a Sharepoint subsite on an existing site collection through the web service api (as oppposed to the object model or RPC), but I see no clear way on any of the Admin.asmx, Webs.asmx, Site.asmx, or Sites.asmx services to do so.
I can see ways to create a full site collection, lists, and list items, but not to create a subsite on an existing site collection.
Can someone please confirm whether or not there is a way on the out-of-the-box sharepoint web services to do this?
It's exceedingly (well, maybe not exceedingly) easy to create your own SharePoint-aware web service. If the existing API isn't sufficient to meet your needs, then you might consider rolling your own to give you more domain-specific functionality. I found this MSDN article to be pretty helpful, and I rolled up the WSDL modifications into a post-build event to simplify the edit-build-deploy process.
http://msdn.microsoft.com/en-us/library/ms464040.aspx
I have googled around and found these 2 references
http://social.msdn.microsoft.com/Forums/en-US/sharepointdevelopment/thread/47d63dbf-3740-4e97-bc5c-17c39ef7b174/
http://community.officesharepointpro.com/forums/post/16971.aspx