Category Archives: SharePoint 2010

SharePoint 2010 – ASPHostPortal.com :: Creating a Custom Login Page for FBA in SharePoint 2010

Introduction

Today I will tell you how to Create a Custom Login Page for FBA in SharePoint 2010.  While as of late assisting my client with their Sharepoint 2010 FBA design, I went over an obviously baffling part of utilizing a custom ASP.NET form to handle the validation. Amid the advancement of custom login page, i came to realize that a large portion of documentation that is accessible on this theme, all that is needed is to give a URL to your structure in Central Administration. The inquiry is do you think it is just conceivable approach to do this by giving URL in Central Admin? The answer is NO. It is conceivable. Lets have some Tea and prepared to ride on this.

Foundation:

It would be incredible if things worked so effortlessly as simply hitting in a URL and the back-end wiring itself up naturally. Lets accept you have an essential ASP.NET form and you’ve arranged it in this way with standard control alongside expecting that you’ve set up the Asp.net Membership SQL database, designed the Membership and Role suppliers, rolled out the vital improvements in the web application, Secure Token Service and Central Admin web.configs and gone into Central Administration to arrange Forms Based confirmation (FBA in Sharepoint 2010),you’d find that all your endeavors would have been for nix – This structure would submissively approve your qualifications against the Membership database and afterward savagely provided for you a lapse when the structure endeavored to redirect you /_layouts/Authenticate.asp

Why this blunder comes? Reason:

A vanilla ASP.NET form inherits from System.web.ui.page – you are no one worth mentioning the extent that Club Sharepoint 2010 is concerned. Since an ASP.NET form has no clue how to make the obliged cases based validation token to pass along to Sharepoint to say that you truly are on “the rundown” and that you know this gentleman inside who can guarantee for you.

Arrangement:

There is no API documentation on this. For this situation, to set your login structure page to inherit from the same class that the out-of-the-case Sharepoint FBA login structure executes: Microsoft.sharepoint.identityprovider.formssigninpage (you can discover this page in the/_forms sub organizer of any Sharepoint 2010 web application that has been set for FBA – 11574 for my situation.

Creating a Custom Login Page for FBA in SharePoint 2010

Presently everyonce thinks about polymorphism, we can get to all the Sharepoint FBA/Claims Auth token creation goodness out-of-the-case FBA structures get “free of charge” utilizing the enchantment of polymorphism.

Creating a Custom Login Page for FBA in SharePoint 20102

You can utilize your own altered expert page likewise in which your modified client control will be incorporated (I have made an expert page with name “Masterforcustomlogin” which contains tweaked html according to my prerequisite).

You can make an organizer likewise in _forms/ (Basically it requires to store pictures if your login page has)

By doing this, you can now adjust your prior FBA login structures to accommodate with the cases based auth necessities for Sharepoint 2010.

My Login page resembles this now (in the wake of performing above steps):

Creating a Custom Login Page for FBA in SharePoint 20103

Once you enter your credentials, you will be authenticated with your membership providers and able to logged in.

Important:
During this development, I observed one thing – When you enter your sharepoint site url into address bar it looks like :

Creating a Custom Login Page for FBA in SharePoint 20104

You can see “http://kirti-p:11574/_login/default.aspx?ReturnUrl=%2f_layouts%2fAuthenticate.aspx%3fSource%3d%252F&Source=%2F”. This _login folder is available in virtual directory of sharepoint site itself. When you select “Forms Authentication” from drop down this url will be changed and looks like:

Creating a Custom Login Page for FBA in SharePoint 20105

It says, while you are accessing Forms Authentication option it refere different master page.

loginpage_61

You have to change master page entry accordingly. Thats it for custom login page.

SharePoint 2013 Hosting with ASPHostPortal.com :: How to fix “Microsoft SharePoint is not supported with version 4.0.30319.225 of the Microsoft .Net Runtime” in PowerGUI

Introduction

banner promo-01

Today, i will tell you about fixing “Microsoft SharePoint is not supported with version 4.0.30319.225 of the Microsoft .Net Runtime” in PowerGUI. This porblem started when I attempt to run some Powershell command against Sharepoint in PowerGUI , I experience some slip message as beneath:

Remove-SPSite : Microsoft SharePoint is not supported with version 4.0.30319.225 of the Microsoft .Net Runtime.

At C:\SiteCreation.ps1:37 char:14

+ CategoryInfo : InvalidData: (Microsoft.Share…mdletRemoveSite:SPCmdletRemoveSite) [Remove-SPSite], PlatformNotSupportedException

The mistake message is really clear that Powergui attempt to run the Powershell command under .Net form 4.0 which is not backed by Sharepoint2010, Sharepoint2010 just help .Net 3.5.so in what capacity would I be able to change the settings so that Powershell does run under .Net3.5 in Powergui? The arrangement is really simple.

Solution

1. Open your windows explorer and explore to C:\program Files (x86)\powergui\ and open the configuration file Scripteditor.exe.config.

2. Change the supportedruntime form under Startup settings by deleting the version=”v4.0″ as underneath.

From :

<startup useLegacyV2RuntimeActivationPolicy=”true”>
<supportedRuntime version=”v4.0″ sku=”.NETFramework,Version=v4.0″ />
<supportedRuntime version=”v2.0.50727″ />
</startup>

To :

<startup useLegacyV2RuntimeActivationPolicy=”true”>
<supportedRuntime version=”v2.0.50727″ />
</startup>

3. Restart your PowerGUI and rerun your script. It works like a charm.

SharePoint 2013 Hosting with ASPHostPortal :: Configures the Application Server and Web Server

The pre-requisites installation in one of my recent SharePoint 2013 farm installations was failing at the step where it configures the Application Server and Web Server role for the Server:

installationerror

 

Further, the error logs had the following entry:

  • Request for install time of Application Server Role, Web Server (IIS) Role
  • Install process returned (0)
  • [In HRESULT format] (0)
  • “C:\Windows\system32\cscript.exe” “C:\Windows\system32\iisext.vbs” /enext “ASP.NET v4.5.30319″
  • Request for install time of Application Server Role, Web Server (IIS) Role – Install process returned (1)
  • [In HRESULT format] (-2147024895)
  • Error when enabling ASP.NET v4.5.30319 – Last return code

Since I did not find much community guidance around this, I thought I’ll do some research myself and post the solution for other’s benefit as well. A little bit of digging around revealed that the IISExt.vbs script file was indeed missing from the C:\Windows\System32 folder. Further research revealed that the script is part of the IIS 8.0 scripting tools. The solution therefore is as simple as enabling the IIS 8.0 Scripting Tools through the Server Roles and Features Wizard. The path to the IIS 8.0 Scripting Tools is shown in the following screen capture:

iis6scriptingtools

That’s it. Your pre-requisites installation should proceed as intended after you install these tools… Good Luck with your install! :D

SharePoint 2013 Hosting with ASPHostPortal.com :: How to Access SharePoint Data from Provider-Hosted Apps Use the Right Context

Recently I have focused on building apps that access, manipulate, and interact with data stored in SharePoint Online with Office 365. If you have done any development using the client-side object model (CSOM) for SharePoint, you understand the importance of instantiating the proper ClientContext object to access data in a particular SharePoint site. The ClientContext constructor takes as an argument the URL of a SharePoint site and allows you to access data stored in the Lists collection of the Web associated with it. In this post, I will discuss the various context objects you should use in your provider-hosted app depending on where the data your app needs to access resides and if the user’s permissions need to be considered. If you have been developing apps for SharePoint for awhile now (and even if you haven’t), I strongly encourage you to use Visual Studio 2013 and the Office Developer Tools for Visual Studio 2013

Host webs and app webs

When dealing with apps for SharePoint, you will become familiar with host webs and app webs:

  • Host web – the SharePoint site to which an app is installed
  • App web – the special isolated site (a unique app web is provisioned for each installation of the app) where the app for SharePoint’s internal components and content, such as lists, content types, workflows, and pages, are deployed

Note that a provider-hosted app is not required to have an app web, and in fact may not need one depending on your business requirements.

Your app will always have Full Control permissions to its app web. However, your app will need to request (and be granted) permissions by the user installing your app in order to access data in the host web. This is handled through the app manifest.
If your app needs to access data in the SharePoint site where it is being installed, you will be working with a host web context of some sort. As you will see, there are actually two different host web context objects, depending on the app authorization policy you choose.
Life made easy, thanks to SharePointContext.cs

When you create a new provider-hosted app in Visual Studio 2013, you have the option to create a new ASP.NET Web Forms or MVC application to serve as your app’s remote web application. If you are using the Office Developer Tools for Visual Studio 2013, you also have the option to convert an existing ASP.NET web application to an app for SharePoint project (really cool!) In either case, you will notice that SharePointContext.cs is added to the remote web application project. This file contains class definitions forSharePointAcsContext and SharePointHighTrustContext, which allow you to create host web and app web context objects based on whether your trust broker is ACS (which it is with Office 365) .
Accessing data in the app web
To access data in the SharePoint app web from your app, use the following pattern:

CSOM (C#)

var spContext = SharePointContextProvider.Current.GetSharePointContext(Context);using (var clientContext = spContext.CreateUserClientContextForSPAppWeb()){Web web = clientContext.Web;

clientContext.Load(web);

clientContext.ExecuteQuery();

ListCollection lists = web.Lists;

clientContext.Load<ListCollection>(lists);

clientContext.ExecuteQuery();

}

REST (C#)

var spContext = SharePointContextProvider.Current.GetSharePointContext(Context);HttpWebRequest listRequest = (HttpWebRequest)HttpWebRequest.Create(spContext.SPAppWebUrl + “/_api/web/lists”);listRequest.Method = “GET”;listRequest.Accept = “application/atom+xml”;

listRequest.ContentType = “application/atom+xml;type=entry”;

listRequest.Headers.Add(“Authorization”, “Bearer ” + spContext.UserAccessTokenForSPAppWeb);

JSOM

var appweburl = decodeURIComponent(getQueryStringParameter(“SPAppWebUrl”));var clientContext = new SP.ClientContext(appweburl);var appWeb = clientContext.get_web();var appWebListColl = appWeb.get_lists();

clientContext.load(appWebListColl);

clientContext.executeQueryAsync(onAppWebGetListSuccess, onError);

Accessing data in the host web

To access data in the SharePoint host web (the SharePoint site where your app is installed) from your app, use the following pattern:

CSOM (C#)

var spContext = SharePointContextProvider.Current.GetSharePointContext(Context);using (var clientContext = spContext.CreateUserClientContextForSPHost()){Web web = clientContext.Web;

clientContext.Load(web);

clientContext.ExecuteQuery();

ListCollection lists = web.Lists;

clientContext.Load<ListCollection>(lists);

clientContext.ExecuteQuery();

}

REST (C#)

var spContext = SharePointContextProvider.Current.GetSharePointContext(Context);HttpWebRequest listRequest = (HttpWebRequest)HttpWebRequest.Create(spContext.SPAppWebUrl + “/_api/web/lists”);listRequest.Method = “GET”;listRequest.Accept = “application/atom+xml”;

listRequest.ContentType = “application/atom+xml;type=entry”;

listRequest.Headers.Add(“Authorization”, “Bearer ” + spContext.UserAccessTokenForSPHost);

JSOM

var appweburl = decodeURIComponent(getQueryStringParameter(“SPAppWebUrl”));var hostweburl = decodeURIComponent(getQueryStringParameter(“SPHostUrl”));var clientContext = new SP.ClientContext(appweburl);var factory = new SP.ProxyWebRequestExecutorFactory(appweburl);

clientContext.set_webRequestExecutorFactory(factory);

var appContextSite = new SP.AppContextSite(clientContext, hostweburl);

var hostWeb = appContextSite.get_web();

hostWebListColl = hostWeb.get_lists();

clientContext.load(hostWebListColl);

clientContext.executeQueryAsync(onHostWebGetListSuccess, onJSOMError);

Note that using JSOM, we still need to construct a ClientContext for the app web before we generate an AppContextSite for the host web, made possible through theSP.ProxyWebRequestExecutorFactory.

A note about the app-only authorization policy

By default, authorization checks in the host web succeed only if both the current user and the app have sufficient permissions to perform the action in question, such as reading from or writing to a list. We are reminded that the user’s permissions are taken into account based on the names of the context and access token objects we use in these scenarios: for instance, CreateUserClientContextForSPHost and UserAccessTokenForSPHost. However, your app has the ability to do something akin to running with elevated privileges using the app-only policyfor authorization. Also controlled through the app manifest, the app-only policy is useful when an app doesn’t need or want to consider the permissions of the current user. In Visual Studio 2013, you can specify that your app would like to have the ability to use the app-only policy by checking this box in the AppManifest.xml editor.
That being said, just because your app is granted this permission does not mean that you can use the same host web context or access token as before to automatically leverage it. To access data from the SharePoint host web (taking only your app’s permissions into account and ignoring the current user’s permissions) from your app, use the following pattern:

CSOM (C#)

var spContext = SharePointContextProvider.Current.GetSharePointContext(Context);using (var clientContext = spContext.CreateAppOnlyClientContextForSPHost()){Web web = clientContext.Web;

clientContext.Load(web);

clientContext.ExecuteQuery();

ListCollection lists = web.Lists;

clientContext.Load<ListCollection>(lists);

clientContext.ExecuteQuery();

}

REST (C#)

var spContext = SharePointContextProvider.Current.GetSharePointContext(Context);HttpWebRequest listRequest = (HttpWebRequest)HttpWebRequest.Create(spContext.SPAppWebUrl + “/_api/web/lists”);listRequest.Method = “GET”;listRequest.Accept = “application/atom+xml”;

listRequest.ContentType = “application/atom+xml;type=entry”;

listRequest.Headers.Add(“Authorization”, “Bearer ” + spContext.AppOnlyAccessTokenForSPHost);

Remember that in order to use the app-only policy, your app must request and be granted this permission by the site owner who installs your app. Also note that there is no JSOM example using the app-only policy because apps that do not make OAuth authenticated calls (such as apps that are only JavaScript running in the app web) cannot use the app-only policy.
As you can see, the code you write in each of the above scenarios (accessing data in the app web, host web, or using the app-only authorization policy) is identical except for the method or property you use from the SharePointContext class to get the appropriate context or access token. Understanding these subtle differences is vitally important when making sure your app has the ability to access and manipulate the SharePoint data it needs.

SharePoint 2013 Hosting With ASPHostPortal.com :: Tips How to Creating a SharePoint development environment

SharePoint 2013 Development Environment

ahp_freehostSHP(1)Creating a SharePoint development environment is a task that can be challenging because the aim is to produce a usable environment, often on resource-constrained hardware. Keep in mind that no amount of tweaking will yield a satisfactory result unless your machine meets the minimum requirements for SharePoint 2013. Here are some tips to keep your dev box humming along nicely:

  • Memory – use as much of it as you can. 8 GB is the absolute minimum and even this amount may cause you some problems. If SQL Server starts paging to disk you’ll get no work done.
  • When using a hypervisor such as Hyper-V make sure you allocate more than 1 CPU core to your SharePoint VM.
  • Set a maximum server memory limit in SQL Server.
  • Don’t create a search service application unless you need one. Those noderunner.exe processes will gobble up lots of memory. You can limit the memory usage by editing the noderunner.exe.config file located in C:\Program Files\Microsoft Office Servers\15.0\Search\Runtime\1.0. Look for the memoryLimitMegabytes attribute.
  • If you have a search service application disable continuous crawling and don’t set any crawl schedules. Crawl your content when you need to.
  • Use Set-SPEnterpriseSearchService -PerformanceLevel Reduced to reduce the CPU impact the search service has on your dev environment.
  • Pause the search service application if you’re not using it.
  • Keep the number of web applications to a minimum. Lots of IIS application pools means increased memory usage.
  • Configure an agressive diagnostic log storage limit. You probably won’t need days or weeks of trace log history at your fingertips.
  • Set the recovery model of your SharePoint databases to Simple. This will eliminate the need for a SQL maintenance plan. Many developers overlook SQL log file rotation until their dev machine runs out of storage.
  • Disable usage data collection (unless you need it).
  • Don’t use your regular domain account to run SharePoint services and don’t make it a local administrator of your development box. Develop and test using different user accounts.
  • Keep in mind that these tips are designed to make your personal development environment responsive and easy to work with. A production SharePoint environment would not need these changes as it should be properly resourced and managed.

SharePoint 2013 Hosting with ASPHostPortal :: Scenario pages for SharePoint 2013

SharePoint 2013 has many great ways to help you get things done. We want to highlight a few of these, so we have created scenario pages that explain a specific scenario and provide content to help you understand, implement, and use it easily.

Scenario pages allow you to view key resources based on selected stages of evaluation or adoption. These stages are represented by colored tiles. Click a single tile for a specific stage or Ctrl-click multiple tiles for multiple stages. As you click the tiles, the scenario page lists the resources for each selected stage.

Content and resources are drawn from many Microsoft Web properties: IT content from TechNet, developer content from MSDN, and Information Worker content from Office.com are all integrated into the scenario page experience. All of the resources you need are available in one place, whether you want to understand:

  • Which features must be configured to support the scenario and how to manage them
  • What namespaces and methods to use to develop customizations for the scenario (MSDN content) Or how to accomplish a specific task in the scenario (Office content)

The following scenario pages are now available:

  • eDiscovery in SharePoint Server 2013 and Exchange Server 2013 . eDiscovery allows you to place electronic holds on documents and email for a legal case or audit. eDiscovery is a great example of a solution that benefits from a scenario page because it provides links to key resources published for SharePoint 2013, Exchange Server 2013, and Lync Server 2013.
  • Personal sites (My Sites) in SharePoint Server 2013 . My Sites technology provides profile data, activity feeds, tagging capabilities, and search results for each SharePoint user in your organization.

When you deploy My Sites, each user gets a starting place in SharePoint that brings together the sites, documents, and other information that they care about and helps them share what they know.

SharePoint 2013 Hosting – ASPHostPortal.com :: Binding SAP UI 5 aka Open UI 5 Table with List data from SharePoint 2013 REST API

Binding SAP UI 5 aka Open UI 5 Table with List data from SharePoint 2013 REST API

ahp_freehostSHP(1)

SAP UI 5 aka Open UI 5 is a new development framework available for SAP developers to expose and consume SAP data as JSON objects via REST API calls. Since it is a JavaScript UI library like jQuery UI, this can be used with any client side application that can make use of JSON

To be frank, this is the biggest client side library I have used so far. When extracted, the runtime files alone comes to 55 MB and the total number of files counts to 4K +
This is huge and bit complex and I am using it for quite some time for one of my SharePoint Project as it is heavily dependent on SAP data and UX design.
This article provides details on how to use SAP UI 5 in a SharePoint Application

Pre-requisites

  1. Download Open UI 5 runtime from http://sap.github.io/openui5/
  2. Extract the content and move it to a new folder named sap-ui5 in layouts folder of 15 hive ( In a typical installation the folder path would be C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\LAYOUTS)
  3. jQuery library to perform REST calls

For this demo, I have directly placed all the files under layouts folder.
Packaging and deploying it through a WSP solution or uploading it to Style Library or any other doc lib directly are also other alternative approaches.
I have also created a new list named “Employees” with columns Title and Location

Note: This article on developing SAP UI 5 applications in Visual Studio provides more details on how to create a basic Open UI 5 application with Visual Studio

Steps

  1. Create a new SharePoint Page
  2. Add a Script Editor Web part to the page
  3. Copy and paste the below code in Script Editor
<script>
 	$.getJSON("/_vti_bin/listdata.svc/Employees", function (data) {
 
 		var sTable = new sap.ui.table.Table({
 			width: "500px",
 			visibleRowCount: 5
 		});
 		sTable.setTitle("Employee Details");
 
 		sTable.addColumn(new sap.ui.table.Column({
 			label: new sap.ui.commons.Label({ text: "Employee Name" }),
 			template: new sap.ui.commons.TextView().bindProperty("text", "Title"),
 		}));
 
 		sTable.addColumn(new sap.ui.table.Column({
 			label: new sap.ui.commons.Label({ text: "Location" }),
 			template: new sap.ui.commons.TextView().bindProperty("text", "Location"),
 		}));
 
 		var oModel = new sap.ui.model.json.JSONModel();
 		oModel.setData({ modelData: data.d.results });
 		sTable.setModel(oModel);
 		sTable.bindRows("/modelData");
 		sTable.placeAt("Emp");
 
 	}, function () { alert('failed'); })
 </script>
 
 <div id='Emp'></div>

Note : If you have placed the libraries in a different location, change the URL before pasting it in the script editor

image.axdEverything is in place you would be able to view a grid similar to the one displayed above

SharePoint 2013 Hosting with ASPHostPortal.com – How To Migrate Content Database From SharePoint 2010 To SharePoint 2013

Migrate Content Database From SharePoint 2010 To SharePoint 2013

In this article, we will take you through the database migration process from SharePoint 2010 to SharePoint 2013. An overview of the SharePoint database migration process to a new server is available on the ShareGate website.

ahp_freehostSHP

Step-by-step to migrate content database

  • Step 1 : Make two servers available for the process. Both the servers need to run on the same environment. For instance, Server 1 should run on Windows 2008, SQL server 2008 and include SharePoint 2010. Server 2 should run on Windows 2008, SQL server 2008 and include SharePoint 2013.
  • Step 2 : You must begin with backing up the data from Server 1. To do this,

a) While on SharePoint 2010, pick the database of the port you want to back-up. Right click and from the options that appear, click Tasks → Back Up.
b) In the subsequent window that opens, click ‘Add
c) Copy the location available under the ‘Destination’ field and save it a notepad for later use.

  • Step 3 : On server 2, launch SharePoint 2013 and create a new web application under any port. If you are not sure, pick port 88.
  • Step 4 : Once a new application has been created, perform the following steps:

a) Under Central Administration, select Application Management Manage Content Databases
b) Under the newly created web application, select ‘Remove content database checkbox’. Click OK and SAVE
c) Under the Content Database section, you should now see a message that reads, “There are no items to show in this view’

  • Step 5 : The next step is to restore the database from SharePoint 2010 to the new server. To accomplish this, copy the WSS_Content.bak file from Server 1 on to the desktop or any convenient location on the computer handling Server 2.
  • Step 6 : In SharePoint 2013, launch SQL Server 2008 and right click on the node titled Database and from the options, choose ‘Restore Database’.
  • Step 7 : A new ‘Restore Database’ window now opens. Here, select the ‘From Device’ radio button and browse through your system folders to select the WSS_Content.bak file that we had earlier copied in Step 5. Click OK
  • Step 8 : Next, under the ‘Options’ tab of the Restore Database window, check the box that reads, “Overwrite the existing database (WITH REPLACE)”. Press OK to continue. A message box appears that confirms the operation. Press OK to close this box.
  • Step 9 : Open SharePoint 2013 and navigate to Central Administration → Application Management → Manage Content Databases. You should now see the WSS_Content.bak file displayed here.
  • Step 10 : On the top of the window, you will see a message. Click on the ‘Start Now‘ link to continue.
  • Step 11 : In the subsequent window, click on the ‘Upgrade the site collection’ option. You will be shown a message box. Click ‘I’m Ready‘ to continue.
  • Step 12 : The upgradation process will now begin. This typically takes a few minutes. Once you are done, you will be shown a message that reads, “Upgrade Completed Successfully”

This completes the process. Your content database migration from SharePoint 2010 to SharePoint 2013 has been completed successfully.

SharePoint 2013 Hosting – ASPHostPortal.com :: Plan the Deployment of Farm Solutions for SharePoint 2013

How To Plan the Deployment of Farm Solutions for SharePoint 2013 ?

ahp_freehostSHPWhile everyone is talking about Apps, there are still significant investments in Full Trust Solutions and I am sure that many OnPrem deployments will want to carry these forward when upgrading to SharePoint 2013.  The new SharePoint 2013 upgrade model allows Sites to continue to run in 2010 mode after upgrading and each Site Collection explicitly has to be upgraded individually.

Not the way it worked in 2010 with Visual Upgrade, but this time there is actually both a 14 and 15 Root folder deployed and all the Features and Layout files from SharePoint 2010 are deployed as part of the 2013 installation.

For those of you new to SharePoint, the root folder is where SharePoint keeps most of its application files and the default location for this is “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\[SharePoint Internal Version]”, where the versions for the last releases have been 60 (6.0), 12, 14, and now 15. The location is also known as “The xx hive.”

This is great in an upgrade scenario, where you may want to do a platform upgrade first or only want to share the new features of 2013 with a few users while maintaining an unchanged experience for the rest of the organization.  This also gives us the opportunity to have different functionality and features for sites running in 2010 and 2013 mode.  However, this requires some extra thought in the development and deployment process that I will give an introduction to here. Because you can now have Sites running in both 2010 and 2013 mode, SharePoint 2013 introduces a new concept of a Compatibility Level.  Right now it can only be 14 or 15, but you can imagine that there is room for growth.  This Compatibility Level is available at Site Collection and Site (web) level and can be used in code constructs and PowerShell commands.

I will start by explaining how you use it while building and deploying wsp-files for SharePoint 2013 and then finish off with a few things to watch out for and some code tips.

Deployment Considerations

If you take your wsp-files from SharePoint 2010 and just deploy these with Add-SPSolution -> Install-SPSolution as you did in 2010, then SharePoint will assume it is a 2010 solution or a “14” mode solution. If the level is not specified in the PowerShell command, it determines the level based on the value of the SharePointProductVersion attribute in the Solution manifest file of the wsp-package.  The value can currently be 15.0 or 14.0. If this attribute is missing, it will assume 14.0 (SharePoint 2010) and since this attribute did not exist in 2010, only very well informed people will have this included in existing packages.

For PowerShell cmdlets related to installing solutions and features, there is a new parameter called CompatibilityLevel. This can override the settings of the package itself and can assume the following values: 14, 15, New, Old, All and “14,15” (the latter currently also means All).

The parameter is available for Install-SPSolution, Uninstall-SPSolution, Install-SPFeature and Uninstall-SPFeature.  There is no way to specify “All” versions in the package itself – only the intended target – and therefore these parameters need to be specified if you want to deploy to both targets.

It is important to note that Compatibility Level impacts only files deployed to the Templates folder in the 14/15 Root folder.

That is:  Features, Layouts-files, Images, ControlTemplates, etc.

This means that files outside of this folder (e.g. a WCF Service deployed to the ISAPI folder) will be deployed to the 15/ISAPI no matter what level is set in the manifest or PowerShell.  Files such as Assemblies in GAC/Bin and certain resource files will also be deployed to the same location regardless of the Compatibility Level.

It is possible to install the same solution in both 14 and 15 mode, but only if it is done in the same command – specifying Compatibility Level as either “All” or “14,15”.  If it is first deployed with 14 and then with 15, it will throw an exception.  It can be installed with the –Force parameter, but this is not recommended as it could hide other errors and lead to an unknown state for the system.

The following three diagrams illustrate where files go depending on parameters and attributes set (click on the individual images for a larger view). Thanks to the Ignite Team for creating these. I did some small changes from the originals to emphasize a few points.

6786.CompatibilityLevelOld_5F00_thumb_5F00_6A8D17FE

6114.CompatibilityLevelNew_5F00_thumb_5F00_4E7EE9C41401.CompatibilityLevelAll_5F00_thumb_5F00_1974EB45When retracting the solutions, there is also an option to specify Compatibility Level.  If you do not specify this, it will retract all – both 14 and 15 files if installed.  When deployed to both levels, you can retract one, but the really important thing to understand here is that it will not only retract the files from the version folder, but also all version neutral files – such as Assemblies, ISAPI deployed files, etc. – leaving only the files from the Root folder you did not retract.

To plan for this, my suggestion would be the following during development/deployment:

  • If you want to only run sites in 2013 mode, then deploy the Solutions with CompatibilityLevel 15 or SharePointProductVersion 15.0.
  • If you want to run with both 2010 and 2013 mode, and want to share features and layout files, then deploy to both (All or “14,15”).
  • If you want to differentiate the files and features that are used in 2010 and 2013 mode, then the solutions should be split into two or three solutions:
  1. One solution (“Xxx – SP2010”), which contains the files and features to be deployed to the 14 folder for 2010 mode.  including code-behind (for things like feature activation and Application pages), but excluding shared assemblies and files.
  2. One solution (“Xxx – SP2013”), which contains the files and features to be deployed to the 15 folder for 2013 mode, including code-behind (for things like feature activation and Application pages), but excluding shared assemblies and files.
  3. One solution (“Xxx – Common”), which contains shared files (e.g. common assemblies or web services). This solution would also include all WebApplication scoped features such as bin-deployed assemblies and assemblies with SafeControl entries.
  • If you only want to have two solutions for various reasons, the Common solution can be joined with the SP2013 solution as this is likely to be the one you will keep the longest.

The assemblies being used as code-files for the artifacts in SP2010 and SP2013 need to have different names or at least different versions to differentiate them. Web Parts need to go in the Common package and should be shared across the versions, however the installed Web Part templates can be unique to the version mode.

Things to watch out for…

There are a few issues that are worth being aware of that may be fixed in future updates, but you’ll need to watch out for these currently.  I’ve come across an issue where installing the same solution in both levels can go wrong.  If you install it with level All and then uninstall it with level 14 two times, the deployment logic will think that it completely removed the solution, but the files in the 15/Templates folder will still be there.

To recover from this, you can install it with –Force in the orphan level and then uninstall it.  Again, it is better to not get in this situation.

Another scenario that can get you in trouble is if you install a solution in one Compatibility Level (either through PowerShell Parameter or manifest file attribute) and then uninstall with the other level.  It will then remove the common files but leave the specific 14 or 15 folder files and display the solution as fully retracted.

Unfortunately there is no public API to query which Compatibility Levels a package is deployed to.  So you need to get it right the first time or as quickly as possible move to native 2013 mode and packages (this is where we all want to be anyway).

Code patterns

An additional tip is to look for hard coded paths in you custom code such as _layouts and _controltemplates.  The SPUtility class has been updated with static methods to help you parse the current location based on the upgrade status of the Site.   For example, SPUtility.ContextLayoutsFolder will give you the path to the correct layouts folder.  See the reference article on SPUtility properties for more examples.

Round up

I hope this gave you an insight into some of the things you need to consider when deploying Farm Solutions for SharePoint 2013. There are lots of scenarios that are not covered here. If you find some, please share these or share your concerns and I will try to add it as comments or an additional post..