In the new SharePoint 2013 App model, the Apps can be hosted in one of the following hosting model: SharePoint Hosted (with in SharePoint Domain), Provided Hosted and Auto Hosted (Outside SharePoint Domain).

One of the biggest issue that we can see with Apps running outside SharePoint Domain is Branding, since these Apps has got separate Home or Landing Pages than SharePoint and does not follow Visual Paradigms like Navigation Menus, Back Link to Home Page and so on similar to SharePoint.

Intranet Users can feel disconnected with the App due to this huge gap in UI Experience.

In order to overcome this obvious issue SharePoint allows to import a very basic version of SharePoint 2013 Chrome into their Apps without apply the Custom CSS Styles manually by means of a Client Side Rendering Control called “Chrome Control”.

The functional implementation details of this control reside in “SP.UI.Controls.js” file located in the new “/_layouts/15” virtual directory or “Layouts” Folder in 15 Hive.

Hope up to this point you grasp a fair understanding in Chrome Control and now it is time to move on to see it in action.

In order to demonstrate this implementation of Chrome Control we will start with a Provider Hosted App as show in below steps:

Create a new SharePoint App Project by selecting “App for SharePoint” project template

Choose Hosting Model as “Provider-Hosted”

Choose “ASP.Net Web Forms Application” as template for provisioning the Remote Site

Specify the Certificate location, decrypting password and Issuer ID (This ID was generated while we configure the S2S Trust for Provider Hosted Apps)

Once the Project has been added to the solution it would look like as below:

I have added a dummy feature to force SharePoint to create an App Web for this App, though this is purely optional.

We can review the App Web using any SharePoint Object Browser, here I am using SharePoint Manager to lookout the same

Also notice that we have changed the Start Page for App to “ChromeCrossDomain.aspx” as highlighted below-

Allowing Read permission for the App in Site Collection Hosting it in AppManifest.xml

Also in the Remote Web Project we have Pages Folder which is containing pages for our App.

We have “ChromeCrossDomain.aspx” page residing inside this folder which will serve as Start Page for this App

Similarly we have Scripts folder which is holding all JavaScript Files in use by this App as shown below

Apart from standard JavaScript Files supporting JQuery, we also have two App specific custom JavaScript Files “ChromeLoader.js” & “CrossDomainExecutor.js” which is implementing the core of Chrome Control for this App

In the Start Page HTML –

Firstly we have to add the “Script” Tags to include custom Javascript Files

Then we need to add a “Div” Tag with id = “chrome_ctrl_container” (you can use any unique value as ID) at the top level as shown highlighted

Now if we explore the code in one of the Custom JS file “ChromeLoader.js”, we can see it as

Step 1 – “getParameterByName” is a helper function that can be utilized to read Query String Parameters from the incoming request

Step 2- Read the “SPHostUrl” Query String Parameter to get the handle on Host Web

appIconUrl – Icon URL that we need to show at the top header of the App

appTitle – Header Title for the App

appHelpPageUrl – Help Page Url for the App

settingsLinks – Links to be shown under settings menu

Step 5- “SP.UI.Controls.Navigation” method is used to load the Chrome Control inside the div with Id = “chrome_ctrl_container” along with settings applied based on the “options” object we created in Step 4

Step 6- Visible the Chrome Control and let the SharePoint UX rendering takes precedence over the App defaults

This is it for loading the Chrome Control in our custom App.

Now let see how we can enable Cross Domain Execution for this App.

If we investigate the other custom JS File “CrossDomainExecutor.js” we can notice the execution as follows-

Step 1- Getting “SPHostUrl” and “SPAppWebUrl” Query String Parameters using “getParameterByName” method as before. “SPHostUrl” provides the Url of Host Web where the App has been installed while “SPAppWebUrl” provided the Url of App Web which we got created during the App Installation (by means of Dummy Feature).

Step 2- Getting the reference of “SP.RequestExecutor.js” JS file in context of Host Web as earlier. “SP.RequestExecutor.js” is used to execute Cross Domain Calls to SharePoint i.e. the Call from SharePoint App (Domain 1) to SharePoint (Domain 2).

Step 3, 4, 5- Instantiating the context of App Web and instantiating the object of AppContextSite to get the handle on Host Web object. Once it is done rest of the things are simply applying JSOM operations

There are quite a number of Must to Have developer tools that every SharePoint Developer must have in its arsenal in order to boost its own Productivity while developing solutions on SharePoint Platform.

Few of the tools which are my personal favorites also are listed below:

CAML Designer 2013

CAML Designer can generate the CAML Query Stubs based on the inputs provided by the developer and can quickly give a handle on even complex query formations.

It is not just about the Formation of Queries but also offers code Transition from actual CAML Query to

SharePoint Manager has got quite a simple and intuitive interface which allows you to quickly and easily navigate down the farm and investigate settings, properties, schema XML and so on. Most of the things in your SharePoint environment can be investigated from this tool.

This tool allows you to quickly navigate the Site Hierarchy and objects, and you can also get a quick handle on Schema of List, Fields and on object properties like Object GUIDs, Object Titles and so on.

ULS Viewer allows you to look into the SharePoint ULS Logs in real time by parsing the Logs. The information (Correlation ID, Date Time Stamp, Event Source Process and so on )exposed by this tool is really useful for productive debugging capabilities.

With the evolution of SharePoint 2013 Developer Dashboard also includes these capabilities of reading & parsing ULS logs. Developer Dashboard contains a separate tab by the name “ULS” where we can see the ULS log entries.

SharePoint Search Tool allows to you create and test SharePoint Search Keyword Query backed up by SharePoint REST API paradigm. It also allows you to analyze the Query Stats and adjust them as per the required output.

This framework can be really helpful to let you verify if your custom solutions are Stable, Complying with Company Policies, Following Coding Best Practices, Well Designed and Maintainable and much more.

This is a Chrome Plugin that allows you configure and investigate REST Queries by configuring and executing REST API Call through the tool UI. It also allows us to look for the Stats of the REST Queries in execution.

This is the similar tool as SharePoint Manager with the only difference that it allows us to connect to SharePoint Sites Remotely using Client APIs. So now no more need to login to SharePoint Server to browser SharePoint Site Objects using this tool.

This is an awesome tool for testing SharePoint Send Mail Functionalities no matter if it is Custom or OOB functionality that we are testing.

It is used to verify if the SharePoint is sending mails to the recipients properly. This tool intercepts the mails that were sending to the recipients by SharePoint and allows you to view them in its own UI.

PowerGUI is one of the best tools available for PowerShell Programming. It provides intellisence support for writing PowerShell Scripts at the same time provides lot of useful windows for Debugging purposes.

The SharePoint Software Factory is a Visual Studio Extension helping SharePoint Beginners, as well as experienced developers to create, manage and deploy SharePoint solutions without having to know schema internals of the SharePoint Artifacts.

Following is the list of few of the features offered by this extension-

SharePoint Solution Deployer helps you to deploy SharePoint solution packages (.wsp) to multiple SharePoint environments. It deploys, retracts and upgrades one or more WSPs and can be extended to perform additional custom tasks in PowerShell before or afterwards.

It provides a simple XML configuration file which allows you to define the deployment environment by using variables i.e. to perform different actions on different URLs depending to which farm you are currently deploying.

Microsoft SharePoint Diagnostic Studio 2010 (SPDiag version 3.0) was created to simplify and standardize troubleshooting of Microsoft SharePoint 2010 Products, and to provide a unified view of collected data.

SPServices is a jQuery library which abstracts SharePoint’s Web Services and makes them easier to use. It also includes functions which use the various Web Service operations to provide more useful (and cool) capabilities. It works entirely client side and requires no server install.

FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements. Many of the issues concern violations of the programming and design rules set forth in the Design Guidelines, which are the Microsoft guidelines for writing robust and easily maintainable code by using the .NET Framework.

We will investigate the working of the following scenarios which are quite obvious while working with SharePoint List & List Items.

Scenario 1 – How to restrict users to delete a certain item

In order to show case this scenario let’s consider an Item “Product-001-1” added to the List called “Products” as shown below:

Now let’s try to delete this item as highlighted below-

As soon as user try to delete the item SharePoint looks for any registered Event Receiver with the List and looking for its Receiver Definition to see what all event this Receiver is allowed to receive and executes it.

In our case we have registered the following Receiver Definition with the list-

Step 1 is to check the type of Event that triggers this Event Receiver by making use of “SPRemoteEventType” Enum and “EventType” Property of the “SPRemoteEventProperties” object

Step 2 is to check the List Title by making use of “ItemEventProperties” collection of “SPRemoteEventProperties” object and ensure that we are handling Delete Events received only from a specific which in our case is “Products”

Step 3 is to check for the desired condition and if satisfied then set “ErrorMessage” and “Status” properties exposed by “SPRemoteEventResult” object.

In this case we have set a user friendly message and set status to “CancelWithError”. For all the valid status values we can look for “SPRemoteEventServiceStatus” Enum.

Step 4 is to return the SPRemoteEventResult object back to SharePoint

The setting we did in Step 3 will let SharePoint to terminate the event raised due user action and return the error message to SharePoint which would be rendered as Error Message for the user as highlighted below-

Scenario 2 – How to get Item Details after Item has been updated

In order to show case this scenario we can consider the same item as above and this time let’s let Edit the item as highlighted below

Now next thing is to investigate the code for registered Remote Event Handler –

Step 3 is to fetch the Items Properties by making use of “ItemEventProperties” collection and preparing a variable to make it use later

It is worth noting that at this point, “ItemEventProperties” collection will contain the Properties of the List Item after the Update got succeed, which means that we can find all the updated values in the respective columns for the list item as highlighted and can consume as needed

Just to keep the story simple we are consuming these values in compiling a message to be written to Windows Event Log.

It is important to notice how we are accessing values of “Title” & “Price” Columns of that Item.

Step 4 is to write this message variable to Windows Event Log

Once execution is successful we can see the message logged in the Windows Event Log as shown below

Scenario 3 – How to validate User inputs using Remote Event Receivers

This scenario will talk on validating user inputs and terminate the execution as soon as the input value falls outside the valid value range.

For instance in this demo we are assuming a hypothetical business requirement demanding “Item Price should not exceed $300”

In order to showcase this validation scenario we can consider the same Item as mentioned above.

Let’s edit the item as shown below

Now specify the Item Price any greater than $300, here we are updating the Product Price as $350

As soon as we try to save the item, SharePoint handover the control to Remote Event Receiver which is registered with this list on Item Updating Event and Event Receiver validate the Item Price value against the specified business logic which on fail produces the error message “Price cannot exceed $300” as highlighted below-

If we look into the logic driving this business requirement we can see

Step 1 is to write the code in “ProcessEvent” handler as this action of updating the List Item is a Before Event [ItemUpdating]

Step 2 is to identify the Event Type and ensure that the business logic should be executed only in case of ItemUpdating event

Step 3 is to identify the Source of Event and ensure to handle the event only if the Source is “Product” List

Step 4 is to read the value of “Price” Field entered by the user

Step 5 is to validate the input Price value against the needed business logic

Step 6 is to set the “ErrorMessage” and “Status” Properties of the SPRemoteEventResult object. Set “Price cannot exceed $300” as Error Message and “CancelWithError” as Status. These properties let SharePoint to terminate the Event generated and no updates to the Item will get persisted.

Finally Step 7 is to capture information about the Item and Event and write it back to Windows Event Log.

These few simple scenarios might help you to understand the mechanics and objects exposed by Remote Event Receiver API that can be extended to achieve even more complex business scenarios at hand.

This small write-up is based on the Presentation made by Bill Baer on “BRK2188 – What’s New for IT Professionals in SharePoint Server 2016” in Ignite Conference ended recently.

In this presentation Bill explained a lot of Enhancements & Improvements in SharePoint 2016, the Public Preview of which is going to hit the market soon. I have compiled the Key Takeaways under different categories as mentioned below-

Release Timeline Milestones

Regarding the release timeline, there are 3 milestones:

Q4 2015 – Public Beta (Beta 1)

Q1 2016 – Release Candidate

Q2 2016 – Final Version (RTM)

Hardware & Software Requirements

Hardware requirements are mostly the same as we have in SharePoint 2013:

Memory: For Single Server Deployment Scenarios it should be 16-24 GB. For Multi Server Deployment Scenarios it should be 12-16 GB

CPU: For either of the Deployment Scenarios it should be x64 Bits, 1 Quad Core

Deployments in Standalone mode (Mode with In-Built SQL Server Express) is not supported

Supported Scenarios:

Deployments on Domain Controller is supported but recommended only for Development/Evaluation or Small Farms Scenarios

Deployment with Single Server Farm recommended only for Development/Evaluation Scenarios

Roles & Services

With SharePoint 2016 Microsoft introduces a new concept “MinRole” that governs the notion of processing a User Request End To End by a specific server. Based on the type of requests, these Roles and Services are broadly categorized under following categories:

WebFrontEnd: This Role falls under “User Services” so this role is meant to serve End User Request. Servers assigned to this role are optimized for low latency. Services complying with this role are:

Access Services

Business Data Connectivity

Central Administration

Managed Metadata

Secure Store Service

State Management

Subscription Settings

User Code

User Profile

Visio Graphics

SharePoint Foundation Web Application

Application: This Role falls under “Robot Services” so this role is meant to serve backend jobs or Servers assigned to this role are optimized for low latency. Servers assigned to this role are optimized for high throughput. Services complying with this role are:

Crawl

Machine Translation

PowerPoint Conversion

User Profile Synchronization

Word Automation

Workflow Timer Service

SharePoint Foundation Web Application

Specialized Load: This is special type of role to support Random Role Assignments as per business requirements like we have in SharePoint 2013. Recommended for Deployment of Isolated Services like 3rd Party Applications etc. This Role is not accounted by Health Checkup Analyzer as this is exempted in the Product Code Base of SharePoint 2016. Services complying with this role are:

Excel Calculation

PerfomancePoint

Project

Search

SharePoint Foundation Web Application

DistributedCache: This Role falls under “Caching Services” so this role is meant to distributed cache for the farm. Servers assigned to this role can load balance end user requests among the Web Front Ends. Services complying with this role are:

This Health Rule will run Daily and scan all the servers in the farm except server assigned to “Specialized Load” Role

The Code Base for this Health Rule compares the Service Instances on each server with the Role assigned to it and verify if the server comply with expected Topology recommendations from Microsoft. If Server doesn’t comply with the expected Topology recommendations, in health analyzer we can see the option to fix it directly from there.

Upgrade & Migration

Upgrade from SharePoint 2010 (UI Mode 14 or 14.5) and SharePoint 2015 (UI Mode 15): Upgrading to SharePoint 2016 will only be supported from SharePoint 2013. If you’re still using SharePoint 2010 or a previous version, you’ll first have to upgrade to SharePoint 2013 and your site collection will have to be converted to 15 mode before you can upgrade to SharePoint 2016.

Migration: You can also choose to migrate content from a previous version of SharePoint using one of the available third party software applications.

Patching

Small Patch Size with no downtime:

Patches and updates will have a smaller footprint and will not require any downtime.

As with most of the new features, the new patching process was developed for SharePoint Online and SharePoint 2016 will now benefit from the lessons learned from managing SharePoint in the cloud.

In SharePoint 2013 an update is comprised of 37 packages and an additional 18 packages for each installed language pack.

In SharePoint 2016, an update is comprised of just 4 packages, plus 1 extra package for each installed language pack.

Boundaries and Limits

In SharePoint 2016, here are the main improvements on different thresholds values:

Content Databases: Supports content databases with TBs (specific number is not yet defined). In SharePoint 2013 Size should not be more than 200GB per content database.

Site Collections: Supports 100,000 site collections per content database. In SharePoint 2013 this limit was 10,000 site collections per content database.

List Items: List item threshold will be over 5,000 items although no specific number is not defined yet.

Max File Size powered by BITS Protocol + Cobalt Protocol + Shredded Storage: Max file size is now 10GB and there won’t be character restrictions. Earlier it was 2GB in SharePoint 2013 with character restrictions. This file size is supported to be Uploaded or Downloaded is powered by combination of BITS Protocol (which is newly introduced in SharePoint 2016), Cobalt Protocol and Shredded Storage.

Search Indexing: Search index can now scale to to hold upto 500 million items which was 250 million items in SharePoint 2013’s search index

Performance and Reliability Enhancements

Some of these improvements were brought to SharePoint 2016 which is expected to support a four-9s availability level (99.99%):

Server role optimizations

Zero downtime patching strategy

Improved distributed cache reliability

Traffic management with intelligent routing and server health checks

Major Performance/Reliability/Flexibility improvements that can be seen in SharePoint 2016:

New File Management Protocols: SharePoint 2010 introduced the Cobalt protocol. With Cobalt, when a document is being edited and the user saves it, only the modified portion of the file is sent by the client application to the server, greatly reducing the amount of data transmitted between client and server. However, the server still has to fetch the whole document from the database and merge the existing content with the user changes before saving the whole document back to the content database. SharePoint 2013 brought the Shredded Storage mechanism which allows documents to be stored in small pieces in the content database. Because documents are already “shredded” in the database, the server does not have to fetch the whole document to merge the original contents with the changes, which reduces the server processing overhead. SharePoint 2016 adds BITS (Background Intelligent Transfer Service) protocol which will improve upload and download speeds and resiliency.

“Fast Site Creation“– A new Site Collection creation process: The new site collection creation process leverages the Copy method to clone a pre-configured site collection template at the content database level. This process avoids the overhead of feature activation since the features are already activated in the source site collection.

SMTP Connection Encryption: With the implementation of new “STARTTLS” connection encryption that supports sending mails to SMTP Servers on default or non-default ports. Earlier with till SharePoint 2013, only Default Port (25) was supported for SMTP Communications but now it is possible to choose any available port with the new “STARTTLS” connection encryption

User Profile Service: In SharePoint 2016 Bidirectional Synchronization has now been improved by removing built-in FIM Services and adding support for External FIM Service.

Support for ODF Format: SharePoint 2016 included support for ODF Format in Document Libraries where documents can now be saved in ODF Format and then can be edited in with program of choice.

UI Improvements

SharePoint 2016 looks and feels mostly like the current version of SharePoint Online (in Office 365), but a few improvements were made to the UI, namely:

Authoring Canvas: New Authoring Canvas, a new and modern way to create content for a web page using a Sway-like user experience

Durable Links: Support for Durable Links which allows documents to be moved while keeping the URL intact, because it is based on a resource ID

Cloud Accelerated Experiences

One of the most touted new features of SharePoint 2016 is the support for cloud accelerated experiences or, in other words, the ability to surface features that are only available in the cloud, using a hybrid scenario:

Compliance: Compliance and data loss prevention (DLP) across cloud and on-premises. Sensitive Data can be Identified, Monitored and Protected through deep content analysis.

Cloud Search Service Application: Cloud search service application which unifies the on-premises and cloud search indexes and provides support for Office Graph / Delve experiences on-premises. As per plan this service will be available to SharePoint 2013 also by the end of this year

Distributed team sites: Distributed team sites across SharePoint 2016 and Office 365

We will revisit the Service Class Code in a short while to understand its internal plumbing.

But for now let’s build the Solution and Run it.

Trust the App with all needed permissions when prompted.

As soon as we Grant the App with all of the required permissions, the App Launcher redirects the User to the Start Page for the App, which is residing in the Remote Web for this case as highlighted below

We can see the App Launcher added to the Site Contents of the Host Web as shown below

We can ensure the presence of App Web by using SharePoint Manager and inspects Products List that has been provisioned to the App Web during the App Deployment

We can browse the App Web from Browser also as shown below

Now in order to test the Event Receiver, let’s create a test item in Products List as shown below

Specify Product Name & Price and Click Save button

As soon as Item gets added, it triggers “ItemAdded” event which is delegated to Remote Event Receiver by SharePoint.

In Remote Event Receiver we have two methods “ProcessEvent” & “ProcessOneWayEvent”.

On Item added we can see Breakpoint hit in “ProcessEvent” Method as shown below

Similarly we can see Break Point hit every time the Item gets updated as highlighted in below steps

Likewise we can see Break Point hit when Item gets deleted as highlighted in below steps

Since we registered the Event Receivers to handle “ItemAdded”, “ItemUpdated”, “ItemDeleted” only so none of the other Events would be delegated to Remote Event Receiver by SharePoint.

In case if any more Events need to be handled we need to add <Receiver> Elements in the Element.xml file associated with Remote Event Receiver as and when needed.

SPRemoteEventProperties Object is your real friend:

“ProcessEvent” method of Remote Event Receiver provides an object called as “properties” that exposes a lot of useful properties that can help us to perform any desired operation on the Web or List or List Item.

Following are the important properties that are exposed by “properties” object: