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.