Archive for category SharePoint
The common stack I am currently using to build SharePoint Online solutions generally consists of the following components:
- Visual Studio console application for remote provisioning
- IonFar Migration framework, https://www.nuget.org/packages/IonFar.SharePoint.Migration/
- Office Dev PnP PowerShell Commands, https://github.com/OfficeDev/PnP/tree/master/Binaries
- SharePoint Online Management Shell, https://technet.microsoft.com/en-us/library/fp161372.aspx
- An Office 365 Developer subscription (essential for anyone doing SharePoint development)
- A central Git repository (e.g. Visual Studio Online), for source control
- TeamCity build (e.g. hosted in Azure), for builds
- Octopus Deploy, for deployment
This stack allows automated deployment of the project against a continuous integration (CI) environment. Simple migration scripts (written in PowerShell) are cumulatively run against the environment, and can be easily promoted to a UAT and then Production environment.
A SharePoint deployment typically has different types of sites, with different levels of governance. The central published site usually has tight governance over structure and information, whereas group and team sites have less restrictions and more flexibility.
This guidance is around team sites, where although the site collection must initially be set up by a SharePoint administrator, at least some team members have administration permissions to the site and can manage the site schema and structure. Read the rest of this entry »
An expanded client-side development model, which includes Apps as well as techniques such as remote provisioning, was released with SharePoint 2013. SharePoint Online does not support server-side development, apart from limited sandbox solutions, so client-side development must be used, whereas for stand alone SharePoint both the new client-side model as well as the original server-side model are available.
I have used several of the different alternatives for client-side development, and thought I would provide my overview of when each is suitable and my current preferred approaches.
Read the rest of this entry »
This post details my thoughts on where to start with branding for SharePoint 2013. In particular, I think Themes (.spcolor, .spfont) are now usable, and recommend to start there, linking to a couple of resources. But first, I talk about what not to do.
What not to do
It might seem like a good idea to get a graphic design company to develop a whiz-bang look for your intranet, then turn around and ask a web development company to turn it into a SharePoint branding. Often this starts out with an HTML reset or HTML boilerplate.
The core SharePoint stylesheets have over 10,000 lines of CSS — unless you want to rewrite all of that, you do not want to be doing a CSS reset. You never know when BI dashboard widget XYZ is going to need to display a green/red traffic light based on some CSS buried deep within the core files.
Don’t do it.
There are many different approachs to using jQuery with SharePoint. Here is a summary of several different methods I have used, including how to get it to play nicely with NuGet.
There are three main decisions to make:
- Decide where to put the jQuery files
- Add the jQuery (and other) library to the project
- Referencing the scripts
Web Service for Remote Portlets (WSRP) is a standard for aggregating content within a host system, allowing the content to come from an external system, yet styling to be provided by the host.
SharePoint has ‘support’ for WSRP since SharePoint 2007, via the WSRP Viewer web part (Enterprise), however while it may technically meet the standard it is all but useless for anything except the most basic of requirements (as at the current version, SharePoint 2013).
According to MSDN “in Microsoft SharePoint Foundation 2010 the preferred method of writing to the Trace Logs is to use the SPDiagnosticsServiceBase class” (http://msdn.microsoft.com/en-us/library/ff512746.aspx).
MSDN also provides some guidance on the trace and event log severity levels to use (http://msdn.microsoft.com/en-us/library/ff604025.aspx), however the WriteEvent() and WriteTrace() methods use slightly different enums; the diagnostics logging configuration in Central Administration is slightly different again, and then you have a third set of values accessed by the PowerShell command Get-SPLogEvent.
The table below shows the mapping of levels from these different sources.
Despite the complicated mapping, in general I think things go in the right direction with events writing to the event log and trace log at the same time, and having a high trace level. The distinction between event logging and trace information is also good, with independently set thresholds.
|None = 0||None = 0||0 (None)||Unassigned = 0|
|ErrorServiceUnavailable = 10||Error||1||Critical = 1 (or ErrorCritical)|
|ErrorSecurityBreach = 20|
|ErrorCritical = 30|
|Error = 40|
|Exception = 4|
|Assert = 6|
|Warning = 50||Warning||8||Warning = 8|
|FailureAudit = 60|
|Unexpected = 10||Unexpected = 10||Unexpected = 10|
|Monitorable = 15||Monitorable = 15||Monitorable = 15|
|SuccessAudit = 70||Information||18||Information = 18|
|Information = 80|
|Success = 90|
|Verbose = 100|
|High = 20||High = 20||High = 20|
|Medium = 50||Medium = 50||Medium = 50|
|Verbose = 100||Verbose = 100||Verbose = 100|
|VerboseEx = 200||VerboseEx = 200||VerboseEx = 200|