While working on a client project recently, I discovered that I needed to explore the option to load multiple CSS files from a different site collection, a Portal site. Additional site collections, in this case, are connected to the portal site to consume resources including lists and dynamically generated content. This is because there will be several hundred site collections created based on the same site template.  However, they will share the basic foundation CSS styles across sites. This gives them the ability to modify the CSS in the main portal site through SharePoint Designer and update/checkin and the changes will be reflected everywhere. This gives more agility/versioning rather than having to compile and deploy a WSP, or have the CSS files and other resources load from the layouts folder.
In order to change any specifics, I load an extra CSS file at the very end of the sequence. This customizes and overwrites any style the client wants. Having said that, when I used the ‘After’ property of the CssRegistration server tag to load these CSS files in order, I ran into many issues for example:

1. SharePoint server tags do not like server code <%…%>
2. The Link tag does not offer the After property so it will load whenever the server finds it
3. CSS files have to be loaded in a particular order to have the After property working correctly.

So in dealing with the pain of loading the CSS from a custom source (url), using CssRegistration soon became a challenge. After going through many options, what seems to have worked was adding the server side code to the head tag of the master page to override the CreateChildControls

<%
 protected override void CreateChildControls()
 {
 CssRegistration css = new CssRegistration

css.Name = SPUtility.ConcatUrls(Common.Settings.PortalSiteUrl, "style library/scss/portal.css")
 css.After = "foundation.css"
 Page.Header.Controls.Add(css);

css = new CssRegistration
 css.Name = SPUtility.ConcatUrls(Common.Settings.PortalSiteUrl, "style library/scss/overwrites.css")
 css.After = "portal.css"
 Page.Header.Controls.Add(css);
 }
 %>

The CssRegistration server code used above to load the CSS files does not work correctly in combination with the CssRegistration server tag if you want to use After property. This is because the server code will be run at the time of controls creation.  Whereas the SharePoint:CssRegistration server tag will load when it’s found on the page. To address this issue I had to convert all the CSS registrations into server side code for loading css files. In other words, you can use the code sample above to load the CSS files dynamically or you can use CssRegistration server tags to load static CSS but you cannot combine the two because it will result in changes to the sequence in which the CSS files are loaded.
Hope this will be of help to many who are looking of ways to loading the CSS from different url.

Sometime ago I came across the issue of handling multiple tasks in parallel. Turned out Windows Workflow Foundation provides a friendly replicator activity. So I decided to use it to develop a workflow that upon kick off reads items from other lists for assignment, business areas and notification lists and spawn multiple tasks dynamically in parallel. The workflow is set to be completed when all the tasks are auctioned by their assignees without waiting one task to be finished before the next task is created (Parallel tasks). The detailed documentation for task manager activity can be found at  http://wsstaskmanager.codeplex.com/ and the custom workflow Visual Studio projects are available to download from http://wsstaskmanager.codeplex.com/releases/view/42171
 

I have been assigned on a project to investigate some issues with SharePoint Variations and the first issue I encountered was the error shows up when I click on Variation Labels link under Site Settings. The error pops up with a message “Object reference is not set to an instance of an object” and correlation ID.
As the error on the screen doesnt tell much I took the correlation ID and looked it up in the ULS logs several times and it appears to be complaining about resource file and the obvious answer to solve the issue to most SharePoint admins was to find the resource file and investigate where to get it from. The USL log looks like this:

Reading ULS logs is sometime tricky especially when you have multi server farms. Though one thing worth mentioning here is that the errors roll up in sequence and the result of the error can be another error which is often misleading and its easy to lose the focus on the point of failure. As you can see in the above error, SharePoint is complaining about cmscore.en-GB.resx which indeed does not exist so one might go and start looking for the file where in reality it has nothing to do with any resource file and the underlying error is the unexpected occurrence of a field called Label.
I went to 14 hive layouts folder and opened up VariationLabels.aspx and turns out the field “Label” is being referened in the SPMenuField code just like this:
<SharePoint:SPMenuField HeaderText=”<%$Resources:cms,VariationLabels_List_Label_ColumnHeading%>” SortExpression=”Title” MenuTemplateId=”variationLabelMenuTemplate” TextFields=”Label“/>
So I started investigating in the right direction however the dilemma was why would OOTB page throw such an exception.
Upon investigating further and getting side tracked several times, I started digging more using powershell and found this excellent post http://passionatetechie.blogspot.com/2011/02/how-to-get-all-variation-labels-for.html about listing the variation labels. I could read the properties of a variation label without a problem so that didnt narrow down the issue either.
So basically VariationLabels.aspx page reads off the Variation Labels list which is a hidden list in the root web. So when you browse to the list, SharePoint redirects it to the VariationLabels.aspx page so not much luck in looking at the data there. So then it struck to me that the error is suggesting that it cannot find the field Label and then I thought to look at Variation Labels list settings by going to _layouts/ListEdit.aspx?List={GUID of Variation Labels list} and compared the field names with the freshly created site collection on a separate VM with variations and to my surprise the name of the Label field was changed to Title. So the variationlabels.aspx page looks reads the item data based on the display name of the field and not internal so it was expecting the display name of the field to be “Label” and not “Title” which is essentially the built in Title field. So I changed the name through SharePoint UI to Label and voila that fixed the problem.
I hope you will benefit from this experience and hopefully save a lot of time troubleshooting this uncommon issue. If there is any lesson to learn from this excercise, its nothing but “Do not mess with OOTB SharePoint resources”. SharePoint provides a great platform to put your customizations in place on top of what already exists without breaking into the existing stuff.

Today I am going to talk about application model in SharePoint 2013. There are tons of hundreds of articles, videos, blogs and msdn how-to videos available online and they are pretty good too. The reason for sharing my thoughts on the subject is to give you a concise, holistic view in couple of paragraphs that may help grasp the concept. You are still going to need to read about the architecture t in order to understand the internal mechanics of how this new framework works but here is a good starting point especially for the new adapters. So lets get going.
For those who are new to exploring and evaluating SharePoint 2013, application model or app model for short is a new concept in SharePoint which provides a framework to which we deploy our applications in SharePoint. The traditional way of deploying was to create all artifacts, declarative, managed server side/client side code, web services etc. and put them all together in one single WSP or spread across in multiple according to their function.
Application model or app life cycle gives a new perspective of looking at not only deploying your application components to the farm but target the specific audience with specific functionality that can work independently or  may have dependencies on the global components (root web) and can interact with those objects outside its own scope. To really grasp this concept, we have to look into application scopes and what their boundaries are.
Applications for SharePoint 2013 or SharePoint 15 run in its own app domain just like any other .net web application.
There are 2 application scopes provided by SharePoint:
Host Web
The Host Web is the app domain or the address space for applications running at the site collection level so that they are shared across all sub level sites. The customizations that are allowed to run in Host Web are Custom actions and web part deployments called app parts. You can deploy Host Web features which sit outside the WSP package in the .app file. I am going to talk about this mystery .app file later in this post but if you want to learn now, feel free to scroll to the application packaging section to learn more about it.
App Web
The app web is an app domain in which application for SharePoint runs. Every app in SharePoint has its own app domain so that the cross site/domain connectivity and scripting is not available and allow for each application to run independently. All App web applications have web scoped features only. There are exceptions to this rule which is beyond the scope of this post but to give you an idea an application can invoke rest based remote web services by specifying RemoteEndpoint in app manifest and using javascript via SharePoint proxy (SP.WebProxy and SP.WebRequestInfo). This has been tested by a colleague of mine and it works. MSDN provides a basic example here http://msdn.microsoft.com/en-us/library/fp179895(v=office.15).aspx
One the other hand if you want to make cross-domain calls from remote server into SharePoint where your app is deployed, you could use a SP.RequestExecutor javascript object to make REST calls. An example to do so is available at http://msdn.microsoft.com/en-us/library/bc37ff5c-1285-40af-98ae-01286696242d.aspx. There are whole bunch of cross-domain scenarios available at http://msdn.microsoft.com/en-us/library/bc37ff5c-1285-40af-98ae-01286696242d.aspx

What happens when you deploy an app for SharePoint?
When you deploy an app on the site, not only a new web is created under the root web with the title of the app and pages deployed under the pages library of the web, a GUID like app ID is appended to the domain to form the URL to access the app.
MSDN provides a pretty good example on this:

For example, suppose that an app, with SharePoint components beyond just the UI elements that can be deployed to a host web, is installed on a host website at the following URL: https://www.contoso.com/sites/Marketing
The app for SharePoint will be deployed to a newly created website with a URL like the following:
http://app-bdf2016ea7dacb.contoso.com/sites/Marketing/Scheduler
Note that this URL has the following structure:
https://App_Prefix-App_ID.App_Base_Domain/Domain_Relative_URL_of_Host_Web/App_Name
The placeholders are defined as follows:

• App_Prefix is any string set by the farm administrator in Central Administration. The default is “default.” In this example the administrator has changed this to “app.”
• App_ID is a hexadecimal number generated internally when the app is installed.
• App_Base_Domain is any string set by the farm administrator in Central Administration. The default is the domain of the SharePoint web application. In this example, the administrator has removed the “www.” and set contoso.com as the app base domain.
• Domain_Relative_URL_of_Host_Web is the relative URL of the parent host web, in this case sites/Marketing.
• App_Name is the value of the Name attribute of the app element in the appmanifest.xml file.

There are two primary reasons for deploying apps to app webs, rather than the host web. Both are related to security.

There cannot be nested apps or webs within the site collection which means all app webs exist directly under the root web.
Application deployment model
There are two basic modes Microsoft provides for developing and deploying a SharePoint app depending upon the features you want your users to work with. These modes are not exclusive so if you want to deploy an application which is hosted on SharePoint as well as in the cloud, you can certainly do so. Let’s see in detail what each mode offers to the developers.
SharePoint-Hosted
All SharePoint specific objects which are the building blocks of the SharePoint application like lists, libraries, instances, templates, features, resources including images, style sheets, etc. In other words only the declarative code can be deployed on SharePoint-Hosted environment and no server-side code is allowed. However, you could use client object model using JavaScript class library (SP.js) to talk to SharePoint.
Cloud-Hosted
All server side (managed) code which you want to deploy for your application goes here. In other words, business logic, data massaging and manipulation happens here. Within cloud-hosted deployment you have the option to either host your app on Microsoft SP App Store called Autohosted or you can deploy it in third party cloud called Provider-hosted.
Provider-hosted apps can be developed in any language of your choice. Be it javascript, php, python, Ruby on Rails you pick as long as it has the ability to get, put, post to request the objects from SharePoint and able to read the response back. Microsoft provides the following support to interact with SharePoint.
i)        CSOM or SharePoint Client Object Model
This is SharePoint client object model which is a managed SharePoint client APIs which you can use to connect and perform CRUD operations on remote SharePoint instance. These set of APIs are not new if you have worked with SharePoint 2010 client object model. You need to install the SharePoint Client runtime to work with CSOM.
ii)       REST/ODATA
Now SharePoint 2013 sites are fully available to be remotely managed using the REST APIs. You can create webs, lists, perform CRUD as well you can perform search and you do not have to use Search.asmx for that. You can also work with user profiles. I had to write my own REST APIs to work with user profiles so I guess I don’t need that any more.
The API’s were introduced in SharePoint 2010 but what’s new is there is a massive extension of these APIs which now lets you not only use ListData.svc but you can interact with Search, User Profiles, Publishing framework, just to name a few. The whole list is available on MSDN. You can perform your CRUD operations using javascript. All you have to do is to send http requests and receive responses using JSON. And believe me its super simple.
Its your choice how you want to work with REST APIs depending upon complexity and resources. The following ways can be adopted to work with these APIs:

• .Net Server side code allows you to simply drop the service reference in your project which will create a proxy for you and you work with the strongly typed objects as well as get intellisense and compile time error checking.
• You can use Javascript to send http requests to SharePoint using REST based URL and receive the response in callback methods. Large implementations can be a bit messy with this however if speed and optimization is the requirement than its the best candidate.

App Security
Application security is another new concept that was introduced with apps for SharePoint. You can configure your application to request certain permissions from the user before it can be used. Its the same security as in Windows 8 or Android devices. This security model is built upon OAUTH. For example if you application require internet connectivity than it must be granted for the first time when it runs.
Application Packaging
A SharePoint app is simply a zipped .app file with following structure:

• AppManifest.xml
• WSP
• Host Web Features

When you are ready to deploy your app and if you are using Visual Studio, just build the project and publish. What publishing does is it compiles the WSP and bundles it up in an .app file with a manifest file or host web features.
The app manifest is where all the magic is happening. It has the title, name, start page and configuration of features to activate, etc. Also it has another major configuration and that is permissions. What permissions does this app require in order for users to be able to use it. So basically it is an added security on top of user security. You can learn all about app security including objects, privileges and permission levels on the links provided at the bottom.
Host Web features
The Host Web features are different than web features which are packaged inside the WSP as normal feature. The host web features allow deploying stuff on the site collection just like site scoped features but only limited to custom actions and app parts. The web host features are deployed by including in the app package a Feature that is not inside the package’s .wsp file and that deploys the components that will go to the host web. This “loose” Feature is called a host web Feature. App parts are deployed to the host web in the same way. The host web Feature consists of a standard SharePoint 2013 feature.xml file and one or more associated elements.xml files.
Wrap up
My 2 cents on the app framework is that Microsoft has kind of left the interpretation of application model to its users and developers. Some might take it and use it as another means of bundling and deploying specific features, some might look at it from security isolation point of view and some would take it as an independent application which bundles related features as well as provides an entry point for users to navigate and interact. The pages deployed by an app work exactly like application pages but reside in pages library and use a different master page for look and feel. One of the things that I most like is the ability for an app to run from SharePoint but have remote counter parts.
The easiest way to start developing your apps is to get yourself a developer site on Office 365 and to get you going with building your first app for SharePoint or understanding the application life cycle, I would encourage and point you to follow the MSDN articles below and watch the videos as those videos are very well presented and will clear your concepts on app development. There are also a few samples available on MSDN

• SharePoint Apps Overview – http://msdn.microsoft.com/en-us/library/office/apps/fp179930(v=office.15).aspx
• Basic SharePoint App – http://msdn.microsoft.com/en-us/library/office/apps/jj163980(v=office.15).aspx
• Client API examples – http://msdn.microsoft.com/en-US/library/fp179912(v=office.15).aspx.aspx
• Client API reference – http://msdn.microsoft.com/en-us/library/office/apps/jj193041(v=office.15).aspx
• Javascript – http://msdn.microsoft.com/en-us/library/office/apps/jj220041(v=office.15).aspx
• Licensing apps for SharePoint – http://msdn.microsoft.com/en-us/library/office/apps/jj163257(v=office.15).aspx
• Cross-domain access – http://msdn.microsoft.com/en-us/library/bc37ff5c-1285-40af-98ae-01286696242d.aspx