Creation of sites, lists, libraries, etc. In SharePoint

Formerly in collateral lists, libraries, site columns, content types, list definitions, etc. in SharePoint, I usually used SharePoint features deployed using WSP scripts or PowerShell scripts. This meant that I had a package that could be deployed to DEV / TEST / PROD.

I work with SharePoint in Office 365 and don’t know how to best provide lists / libraries / functions in SharePoint.

Options:

There are no sandboxed solutions Trying to avoid using this data as information from Microsoft about whether it is obsolete is fuzzy - however, sandboxed solutions will allow me to deploy functions with list definitions, etc. I know that isolated solutions with C # support are definitely outdated, but the information around without code solutions is poor.

Applications I know that applications can be provided both at the application level and at the host level, but creating lists, libraries, etc. using CSOM seems like a big effort and a step back.

PowerShell SP Online PowerShell is nowhere more powerful than SP-SP. I can provide collections of sites through this, but not lists or libraries ...

I'm interested in learning how other developers are deploying Office 365, in particular, to create sites with specific list definitions, libraries, content types, etc ...

thanks

+6
source share
2 answers

Microsoft clarified 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 want to use Powershell for deployment, you can go the way of using CSOM from PowerShell - SharePoint Client Browser for SharePoint 2013 is good for setting up a session, which is also very good for viewing the contents of 365 tenants - http://spcb.codeplex.com /

+3
source

I have been using the code position for almost two years without any problems. The server-side model works very well, CSOM has some limitations, but is classy cool, and JSOM can provide the same set of functions as CSOM and SSOM, sorta 95% :)

PowerShell is not the best option, since it is difficult to integrate it into CI, put some unit tests and regressions.

As you mentioned, this is a β€œstep backward,” but unless you have any basis or basis for this. My libraries are internal, but there is SPGenesis in codeplex and SPMeta2. Since the community does not really care, needs or with such libraries to provide (yes, let it occur), there are a lot of such libraries, but there are many examples of "MVP" of the "hello world" sort.

Finally, I would suggest spending your time and effort writing code. This is the future, what it is;)

UPD

Fighting the inconsistency of the SharePoint API, bugs, design behavior, inappropriate time to write, maintain, and update WSP and XML packages, the passionate SharePoint team decided to create a reliable, verifiable, and repeatable way to deploy artifacts such as fields and content types , libraries, pages and more.

Enjoy and let us know how this happens.

0
source

All Articles