månadsarkiv: september 2015

Kom igång med SPMeta2

SPMeta2 (eller bara M2) är ett relativt nytt ramverk för provisionering av SharePoint-artefakter. Bakom ramverket ligger ett gediget arbete. I den här posten vill jag skriva upp mina steg för att sätta upp ett litet projekt. För mig är SPMeta2 nytt och huvudprincipen i den här bloggposten att få en fungerande lösning så snabbt som möjligt. Informationen här kan snabbt bli inaktuell, eftersom SPMeta2 förändras och förbättras väldigt snabbt.

Vad är SPMeta2
SPMeta är ett ramverk för att provisionera SharePoint-artefakter, allt från fält, innehållstyper, listor, dokumentbibliotek, user custom actions, ladda upp filer med mera. Klassiskt har vi gjort provisionering med hjälp av XML-baserade moduler och features. SPMeta2 erbjuder ett Fluent API som är kodbaserat. Med hjälp av SPMeta2 definierar man en modell (enkla objekt POCOs) som inte har beroendet till SharePoint. Modellen används sedan av Provision-delen som anropar modellen för specifika versioner: SharePoint 2013, SharePoint 2010, Office 365 med mera. Man kan välja CSOM och SSOM. Provision är också flexibel vad som gäller paketering: det kan vara en konsolapplikation, en SharePoint-app, ett wsp-paket, en PowerShell-modul. Se följande länkar:

Testmiljö

För att testa behöver vi en site. Jag använder min http://dev/sites/004 som jag skapat just för det här. Av någon anledning gick det inte att använda Visual Studio 2015. Så jag har min Visual Studio 2013 på en virtuell maskin med SharePoint.

Målet

Provisionera jQuery och ett enkelt skript till min site collection.

Process

Installera Visual Studio Template

m2-001

Det här kommer leda till github. Ladda ner den därifrån:

m2-002

Godkänn och Installera

m2-003

Skapa ett nytt projekt. Solution ska vara Takana. Projektet ska vara Takana.Model

m2-004

Välj “Pocos only” och Takana som prefix och gruppnamn (i mitt litet labb kommer de här inte användas, men det går så snabbt att ställa in dem här):

m2-005

Man får en bra struktur över modellen, allt prefixat och enligt best practices.

m2-006

Jag kommer att använda de här modellerna sedan:

m2-007

Nästa steg är att skapa Provision-delen. Skapa ett nytt projekt i samma VS Solution. Kalla det Takana.Provision:

m2-008

Välj SharePoint Standard och SP2013 CSOM

m2-009

Efter det har vi en VS Solution med två projekt: Takana.Model och Takana.Provision. I Takana.Provision finns CSOMProgram.cs som startar provisioneringen:

m2-010

För att börja med, behöver man sätta Takana.Provision som Startup Project (blir fetstilt)

m2-011

Efter det måste ett tillfälligt problem lösas – referensen 16-foldern. Det här ett känt problem och kommer förmodligen lösas inom kort.

m2-012

Den snabbaste vägen till att ersätta referensen är att installera ett nuget-paket som heter SharePoint Online Client Side Object Model. Även om det är för SharePoint Online, funkar det alldeles utmärkt för OnPrem också.

m2-013

Efter det lägg till Takana.Model som referens

m2-014

Byt ut siteUrl, siteModel och rotWebModel:

m2-015

Det går fort att köra den här konsolapplikationen. Nu när jag går in på min site, ser jag att jQuery har provisionerats och ett litet skript också som skriver till konsolen.

m2-016

Sammanfattning

Det här en liten manual för hur man lätt kan komma igång och prova SPMeta2. SPMeta2 är ett kraftfullt ramverk som kan användas för provisionering och uppdatering av SharePoint-applikationer. Det kan finnas en tröskel i att börja använda det. Jag hoppas att med den här bloggposten jag kan göra fler nyfikna på att prova SPMeta2 och kodbaserad provisionering för att det är ett framtidssäkert sätt att arbeta med SharePoint.

Method “GetList” does not exist

I troubleshooted a piece of CSOM code in SharePoint 2013. I got the following error:

Method “GetList” does not exist

The reason was that the method GetList was not imlemented until March 2015 CU (15.0.4701.1001), and the SharePoint farm I had was SharePoint 2013 SP1 (15.0.4569.1000). So the solution is to install the Cumulative Update or use web.Lists.GetByTitle. GetByTitle has one aweful shortcoming: it doesn’t work in multilingual environments. So I have recommended to install the March 2015 CU.

Onpremifying SharePoint apps

onpremify-001

We want to make an app available in SharePoint OnPrem, we want to onpremify it. Rethink SharePoint apps and provisioning SharePoint artifacts.

It has been a while since I updated my blog – Chuvash.eu. I had my vacation, I visited the sunny and green Chuvashia. Now I am back and I am looking forward to an awesome SharePoint Autumn. One of the first things I had to deal with in this SharePoint Autumn was Onpremifying of a SharePoint Online App. We have an app that has gained popularity and we want to make it available for SharePoint OnPrem. There is no such word Onpremify (yet?), I know, it is a Swenglish happy word making (onpremifiera), but I like the word “onpremify” a lot.

There is still uncertainty around the purpose of SharePoint apps. One app type, though, has been used a lot in our company: an app that provisions SharePoint Artifacts – that creates SharePoint Applications. What I mean by SharePoint Applications can be read in my blog post:

  • What is a SharePoint Application (Not written yet).

The successful app type creates SharePoint Applications – by provisioning needed SharePoint artifacts (Fields, Content Types, Lists, Page Layouts, Styles, Scripts, Web Parts, Pages…). Often it is a one time job: When the SharePoint application is provisioined, it is finished.

onpremify-002

When you’re about to onpremify such an app, you have three main choices:

  1. Install app in OnPrem. Requires the App Infrastructure in place and a separate build of the app (15.0.0.0 version)
  2. Make a parallel version of the app using a farm solution (not good at all)
  3. Invoke the provisioning code from a console app (I recommend this one)

The choice 1 might seem obvious, but not all companies have a functioning app infrastructure (a dedicated server for Provider Hosted apps, S2S Trust and Governance around it). The choice 2 splits your app into two variants and makes it hard to maintain.

On the other hand, the choice 3 might seem crazy, when you hear it for the first time. A Console App? But give it time, think about it. The idea comes from the awesome SharePoint Provisioning Library SPMeta2, where the Model (SharePoint Artifacts) and Executing are separated. Your model for Fields, Content Types, and Lists and so on, is an agnostic code based definition that can be used for SSOM and CSOM, for SharePoint 2013, SharePoint Online, SharePoint 2016 and SharePoint 2010. SPMeta2 eliminates the need for XML and wsp packages.

So my recommended approach for onpremifying SharePoint apps where the main goal is to provision SharePoint Applications is to move the provisioning code into a separate VS Project. The SharePoint App Project (mainly AppManifest.xml) remains the same, The App Web Project is made to a “stupid” interface that invokes the Provisioning Library. We also create a new interface – a Console App. You can replace the console app with a Windows Application, a Web Application, PowerShell Script, An admin page in Central Admin – whatever suits you. The Console app can be used not only in OnPrem, but also in SharePoint Online.

SPMeta2 vs. PnP vs. Own Framework

Every developer with Self-Respect uses a framework for provisioning SharePoint artifacts. It might be some own utilities or preferably public framework, because you don’t want to repeat yourself, especially in SharePoint. When SPMeta2 and PnP are available it is not smart to reinvent the wheel. I usually recommend to use one of them. I personally prefer SPMeta2 because… mainly because it is more complete and consistent. Read more about SPMeta2 vs. PnP comparison.