This post is a contribution from Paul Chan, an engineer with the SharePoint Developer Support team

This blog article will list the popular tools that can be used when troubleshooting performance issues. Note that the tools being mentioned here are listed in random order.

NOTE: If you feel needed or press on time, feel free to contact Microsoft and create a support case to work with us, instead of dragging the resolution of the issue for too long until the last minute.

Task Manager: This is the first tool can be used to identify high memory and high CPU scenario; e.g. to check if it is the w3wp.exe process taking a lot of memory or CPU cycles. This tool is always available from the OS. However, it only gives a high level point of view with no specific details.

Performance Monitor: This is another tool to identify which process is taking high memory or CPU. It also provides a logging option that you can track the usages in a period of time. However, it still won’t give you the clear target where the issue comes from.

Custom Logging: This method is being mentioned in both the high CPU and slow issues (in Part 2 and Part 3). To be honest, it is more useful in slow issues than high CPU issues. This method could be the one that give you the clearest target where the slowness come from.

Code Review: Although code review is the method being mentioned in all 3 types of performance issues, it is not really troubleshooting but trouble-scanning; i.e. it’s not shooting at any specific target but more like shooting in the dark; especially when it’s up to high memory usage. This is the main tool to use that fits all 3 types of performance issues though.

NP .NET Profiler: I mentioned it in Part 1 and 3 before. This is a nice tool but it does have its limitation. I think it can also be used in small scale code tests as well. One of the good things about this tool (if it does apply) is it doesn’t need to modify any code that it attaches itself to the process to do the profiling. But the main drawback is it needs to terminate the process when attaching and detaching itself.

Microsoft SharePoint Development Support: What do we do in our support team? Do we have any secret scrolls or magic spells? Maybe someone in the team does, but not me. Basically, we troubleshoot performance issues using the similar tools I mentioned as the condition fits. Of course, we might also use some tools that only available internally in Microsoft. Personally, I also rely on memory hang dumps to troubleshoot performance issues. However, this specific topic is too much to cover that it is not suitable to discuss in a small blog article like this. Memory dump analysis is not an internal thing to Microsoft only, you can look it up over the internet and you will find people discuss about it.

DebugDiag: This is a tool that associated to the memory hang dumps mentioned above. This tool provides an Analysis feature that it does the memory dump analysis via a script. So it kind of sits between a memory hang dump analysis done by a human being, and the tools that only give a high level overview of the issue. However, everyone have an uncomfortable feeling about analyzing data automatically done by a script. On the other hand, understanding its analysis results could be challenging as well. However, it is better than nothing, and don’t get me wrong that it is in fact a good tool. I personally use this tool as a reference in addition to my own memory hang dump analysis. Talking about how to use this tool will take a long time, not to mention how to read its results. Obviously, I will not include such information in this blog article. Lookup the term DebugDiag over the internet and you will find a lot of references about it.

ULS Log: This tool has been overlooked from time to time that people usually open the logs when there is an error pops up along with a correlation Id. Performance issues usually don’t apply to this because they are not really errors or exceptions from the code, but a symptom caused by the environment (exposed by the code). However, sometimes the ULS logs will provide useful information; such as query time taken, that could help in slow issues. If you are using the SPMonitoredScope to do the logging in the code, the log also provides the timestamp and what activities are happening around that time. Looking into ULS log without correlation Id is painful and need patience, but sometimes this is what needs to do.

NOTE: For any performance issues that you don’t feel comfortable to handle, please feel free to create a support case and work with Microsoft support. We do not want the resolution of our customer issues being delayed.

This post is a contribution from Paul Chan, an engineer with the SharePoint Developer Support team

Another popular performance issues I have seen when working on customer’s issues is slow response. Obviously, this blog article addresses a slow scenario.

NOTE: If you feel needed or press on time, feel free to contact Microsoft and create a support case to work with us, instead of dragging the resolution of the issue for too long until the last minute.

The symptom of a slow issue could be confused by high CPU usage. When a process is using high CPU utilization, its response is obvious slow. This condition is not considered a slow issue but high CPU instead. Similarly, a slow response could also being caused by high memory (or I should say high resource) usage. Failing to release resource from the class objects being instantiated in the code could lead to a slow response; especially if the resource related to network connections. In theory, it is not high memory usage will cause a slow response directly, but indirectly. For a “real” slow issue, it means the CPU and memory usage are usually low, which technically means that the w3wp.exe process is waiting on something; more likely some requests to a remote process, web service, SQL, etc.

If you do have access to the custom code and afford to change and redeploy it, then the most simple way is to add time logging in the code; i.e. either log the time at selected location in the code and record the time (or the duration of a method or section of the code) into a text file or anything available. Then simply check the time and reference in the code will give you an idea where in the code execution is taking a long time. The DateTime.Now, the System.Diagnostics.Stopwatch, or the Microsoft.SharePoint.Utilities.SPMonitoredScope will be useful in this approach.

If you can’t change the code, try to see if the code will attempt to connect to any remote services, and then check the remote side of the request and see how long it takes. For example, if the code will try to access a web services hosting by a website on an IIS server, simply check the Time-Taken column value in the IIS log of the hosting website will give you an idea how long the request to the web method took.

For SharePoint specific issues, the access to lists with a lot of items (e.g. 2000+ items) could be a problem. Complicated CAML queries should be avoided, prevent expensive operations (e.g. break inheritance, create new site, etc.). In addition, the ULS log might give you some clue (e.g. a query duration time) to show where the slowness could come from.

For a tool that could help troubleshooting slow response, a code profiler will be nice, but not everyone has access to one. There is one I mentioned in “How to troubleshoot performance issues in SharePoint custom code on your own? Part 1 – High Memory Usage” that is not very friendly but could somewhat do the job (with certain limitations); i.e. NP .NET Profiler. You can read about it (contains some simple walkthroughs):

http://blogs.msdn.com/b/webapps/archive/2012/09/28/troubleshooting-performance-issues-in-web-application.aspx

Can be downloaded from here:

http://www.microsoft.com/en-us/download/details.aspx?id=35370

NOTE: For any performance issues that you don’t feel comfortable to handle, please feel free to create a support case and work with Microsoft support.

This post is a contribution from Paul Chan, an engineer with the SharePoint Developer Support team

One of the popular performance issues I have seen when working on customer’s issues is high CPU utilization (aka 100% CPU, or high CPU).

NOTE: If you feel needed or press on time, feel free to contact Microsoft and create a support case to work with us, instead of dragging the resolution of the issue for too long until the last minute.

When troubleshooting a high CPU issue on your own (i.e. not working with a Microsoft support engineer), it could be very complicated. Most of the time there isn’t much can be done but code review.

The first thing to confirm is which process is running on high CPU. This can be verified by simply looking into the Task Manager of the server. If it is a custom code on SharePoint server, the w3wp.exe process is what we’re looking into.

From my experience, there is about 40% of the time a high CPU issue actually caused by high memory usage. What could happen is the memory usage is too high that it triggers .NET garbage collection (GC) more often than it should have. Since GC is an expensive operation, the CPU will go high whenever GC is occurring. In such situation, resolving the high memory issue will lower down the CPU usage. Check the memory usage of the w3wp.exe process will give you an idea if it’s running on high memory or not (or take a look to the article “How to troubleshoot performance issues in SharePoint custom code on your own? Part 1 – High Memory Usage”).

What if the memory usage appears normal? Then we move on to code review. What to focus is any type of loop, foreach, while, etc. and any repeated operations. It is usually not a single call of API will lead to 100% CPU, but a lot of API calls that being executed repeatedly.

Another way “try” to find out where in the custom code that leads to 100% CPU is to logging. Simply add some logging/reporting code (e.g. write to a text file, SharePoint list, etc.) in the code from the beginning to the point that you suspect where the issue could be. When the log shows that an expected entry (and further) is missing, then it means the issue occurs after the last recorded entry and before the missing entry, because the code being executed before the logging is too busy that it doesn’t get the chance to execute the logging piece until after a long time. This could help narrow down the focus in the code.

There seems no clear way to identify a line of code that uses large amount of CPU power. What exactly need is the information about the CPU usage of a thread in the process. Since w3wp.exe process is going to run multiple threads, getting the CPU % from the w3wp.exe process cannot identify which thread is using high CPU. Even if we can tell which thread is using high CPU (e.g. from Performance Monitor’s Thread object, % User Time counter), we still need to tell what kind of code a specific thread is executing. Is this impossible? No, but it is a bit tricky try to get such information in a practical world. The type and amount of information to describe the process will not fit in this little blog article however.

NOTE: For any performance issues that you don’t feel comfortable to handle, please feel free to create a support case and work with Microsoft support.

This post is a contribution from Paul Chan, an engineer with the SharePoint Developer Support team

One of the popular performance issues I have seen when working on customer’s issues is high memory usage. Note that performance issues in Microsoft development support are divided into different categories; i.e. a) High memory usage; b) High CPU utilization; c) Slow. One of the main things we will need to distinguish is what type of performance issue we are working on. Obviously, this blog article addresses a high memory usage scenario.

NOTE: If you feel needed or press on time, feel free to contact Microsoft and create a support case to work with us, instead of dragging the resolution of the issue for too long until the last minute.

There may be special tools or techniques that a Microsoft support engineer uses that depend on the nature of the issue. It is not the intention of this blog to discuss about those special things, but something that any developers can do. Most of the approaches being discussed here will also being used by Microsoft support engineers as well.

When troubleshooting a high memory usage issue, it is either very simple or very hard. Under a single blog article like this one, I only talk about the simple scenario here. The majority of high memory usage in custom SharePoint code related to the instantiation of the SharePoint class objects (e.g. SPSite & SPWeb) but not disposing them in the code after using them.

The quite popular tool SPDisposeCheck (http://download.microsoft.com/download/B/4/D/B4D279A0-E159-40BF-A5E8-F49ABDBE95C7/SPDisposeCheck.msi) is created to check such objects in the dll. This tool is created by Roger Lamb that the results of the tool reference the sections in his own blog articles where he talks about the scenarios. Here are a couple of his articles that worth to take a look:

http://blogs.msdn.com/b/rogerla/archive/2008/02/12/sharepoint-2007-and-wss-3-0-dispose-patterns-by-example.aspx

http://blogs.msdn.com/b/rogerla/archive/2008/10/04/updated-spsite-rootweb-dispose-guidance.aspx

Since Mr. Lamb already has some quality articles written, I’m not going to repeat what he has covered but talk about something else.

There are two main causes of high memory usage; i.e. a) memory leak; b) high memory usage by design.

How do we know there is a high memory usage issue on a SharePoint site? What is considered high? Basically, we measure the memory usage of the w3wp.exe worker process that runs the SharePoint site; e.g. a quick look into the Task Manager will give a rough idea. If it is using close to or over 1GB of memory in a 32 bits OS, then it’s consider high. In 64 bits OS, having a w3wp.exe process running with 2GB of memory is quite normal, and even up to 4GB. Note that these are just rough figures for reference only that the real life situation could different in a site by site basis.

Another thing to check is to run a Performance Monitor logging to check the w3wp.exe process’s Private Bytes and Virtual Bytes counters in the Process object for a period of time. If you see a trend that the counters keep rises, then there is likely a memory leak. If you see a trend that the memory rise at the beginning, and then kind of goes flat (at a relatively high memory usage value) eventually, then there is a high memory usage.

Personally, I don’t consider high memory usage necessary a problem unless the server cannot handle such memory usage and causing issues to the site. But it will be good to minimize the usage if possible. The problem that introduces a bigger negative impact is memory leak, which means potentially the process will use up all the memory or until a critical issue occur to the site.

The way to handle both types of memory usage issues is quite the same; i.e. code review (if you’re not going to work with a Microsoft support personnel). For memory leak that specific in SharePoint class objects, we are lucky to have the SPDisposeCheck tool. However, developers can put any type of code that uses any class objects in it. There are other non-SharePoint class objects that also need to dispose. A few popular one I have seen are; e.g. WebResponse (also the Stream object from the WebResponse.GetResponseStream method), web service proxy, DirectorySearcher, IO Stream, etc. The general rule is: Whatever objects you use the “new” keyword to instantiate and that class object does expose a Dispose (or Close) method, dispose it. Sometimes it is not only concern memory usage, but also any resources the specific object going to use (e.g. network connections).

Wait, I didn’t say much here that help but just SPDisposeCheck (that a lot of people know about it already) and code review. For another tool that could help troubleshooting performance issues, a code profiler will be nice, but not everyone has access to one of them. There is one that not very friendly but could somewhat do the job (with certain limitations); i.e. NP .NET Profiler. You can read about it (contains some simple walkthroughs):

http://blogs.msdn.com/b/webapps/archive/2012/09/28/troubleshooting-performance-issues-in-web-application.aspx

http://blogs.msdn.com/b/webapps/archive/2012/09/29/faq-on-np-net-profiler.aspx

http://blogs.msdn.com/b/webapps/archive/2012/11/08/list-of-blog-posts-on-np-net-profiler.aspx

Can be downloaded from here:

http://www.microsoft.com/en-us/download/details.aspx?id=35370

Note that this blog is not meant to give a training or walkthrough how to use the .NET Profiler. Such information can be found in its own site already. I simply mention it and hope that it does help.

NOTE: For any performance issues that you don’t feel comfortable to handle, please feel free to create a support case and work with Microsoft support.

This post is a contribution from Aaron Miao, an engineer with the SharePoint Developer Support team

SharePoint 2013 SPSecurityEventReceiver provides methods to trap events that are raised for security. Tim Ferro’s this blog provides great details missing from MSDN document about the class.

This blog is to provide one detail about the issue of canceling RoleAssignmentAdding event.
With the code below,

public override void RoleAssignmentAdding(SPSecurityEventProperties properties)

{

base.RoleAssignmentAdding(properties);

// more code here: if user is “everyone” cancel the adding

string errMsg = "This user is not allowed to be added to this site";

properties.ErrorMessage = errMsg;

properties.Status = SPEventReceiverStatus.CancelWithError;

}

when adding a user from _layouts/15/user.aspx page, like this (adding “everyone” to a team site with explicitly specifying Read permission):

You would expect an (out-of-box) error page shows up with the error you set like below.

This works just fine with GroupUserAdding event (adding a user without explicitly specifying permission). However the error page won’t show up when canceling RoleAssignmentAdding event. This due to a defect in SharePoint product. The problem will be likely addressed in next release of SharePoint.

Fortunately you can work around the issue by creating a custom error page. This blog has all the details about SharePoint 2013 event receiver redirect.
Code (as described in the blog) like below should lunch your custom error page to notify users.

private readonly HttpContext _currentContext;

public UserAddingEventReceiver(ISecurityEventConfig config)

{
   _currentContext = HttpContext.Current;

}

public override void RoleAssignmentAdding(SPSecurityEventProperties properties)

{

base.RoleAssignmentAdding(properties);

string url = new StringBuilder("CustomErrorPage.aspx");

string urlRedirect = null;

// more code here: if user is “everyone” cancel the adding

string errMsg = "This user is not allowed to be added to this site";

properties.ErrorMessage = errMsg;

properties.Status = SPEventReceiverStatus.CancelWithError;

bool flag = SPUtility.DetermineRedirectUrl(url.ToString(), SPRedirectFlags.RelativeToLayoutsPage, _currentContext, null, out urlRedirect);

_currentContext.Response.Redirect(urlRedirect + "&Error=" + errMsg, true);

}

This post is a contribution from Aaron Miao, an engineer with the SharePoint Developer Support team

With SharePoint 2010 you can set time zone for a user using code like this:

// Code1
using (SPSite cSite = new SPSite(siteURL))

{

using (SPWeb curWeb = cSite.RootWeb)

{

curWeb.AllowUnsafeUpdates = true;

SPUser editUser = curWeb.EnsureUser(loginName);

SPRegionalSettings userRegSettings = new SPRegionalSettings(curWeb, true);

userRegSettings.TimeZone.ID = 10; // see List of TimeZone ID

editUser.RegionalSettings = userRegSettings;

editUser.Update();

curWeb.AllowUnsafeUpdates = false;

}

}

After the code is executed, you can browse to a Document library to check a datetime column, for instance, Modified. It shows the datetime in the time zone you set.

However this is reported not working any more with SharePoint 2013. The reason is that SharePoint 2013 sets default value of User Profile property “SPS-RegionalSettings-Initialized” to false, which is true in SharePoint 2010. You need first to set the property to true like this:

// Code2
using (SPSite ccSite = new SPSite(siteURL))

{

SPServiceContext serviceContext = SPServiceContext.GetContext(ccSite);

UserProfileManager userProfileMgr = new UserProfileManager(serviceContext);

UserProfile updUser = userProfileMgr.GetUserProfile(loginName);

updUser["SPS-RegionalSettings-Initialized"].Value = true;

updUser.Commit();

}

If you execute the Code1 immediately after Code2 you will find that the user still see datetime column value (e.g. Modified) in old time zone.

This is because the timer job “User Profile Service Application - User Profile to SharePoint Language and Region Synchronization” (scheduled for 1 minute interval) has not completed yet. Setting ["SPS-RegionalSettings-Initialized"].Value to true will cause synchronizing language and region information from the User Profile service application to SharePoint users.

To set a time zone for a user on a site, first run Code2, set some time delay to allow timer job “User Profile Service Application - User Profile to SharePoint Language and Region Synchronization” to complete synchronization and then run Code1.

This post is a contribution from Paul Chan, an engineer with the SharePoint Developer Support team

A customer brought an issue to my attention recently that using the server-side object model Microsoft.Office.Server.Search.Query.SearchExecutor class with Query Rules defined in SharePoint could get inconsistent relevant results.

There is a popular code example about the use of the server-side SearchExecutor class to search with relevant results. The example can also be found in this MSDN article: http://msdn.microsoft.com/en-us/library/office/dn423226(v=office.15).aspx as follow:

using (SPSite siteCollection = new SPSite("<serverRelativeUrl>"))

{

KeywordQuery keywordQuery = new KeywordQuery(siteCollection);

keywordQuery.QueryText = "SharePoint";

SearchExecutor searchExecutor = new SearchExecutor();

ResultTableCollection resultTableCollection = searchExecutor.ExecuteQuery(keywordQuery);

resultTableCollection = resultTableCollection.Filter("TableType", KnownTableTypes.RelevantResults);

ResultTable resultTable = resultTableCollection.FirstOrDefault();

DataTable dataTable = resultTable.Table;

}

It is found that when checking the DataTable (dataTable), the number of results is different sometimes.

The focus of the issue here is resultTableCollection.FirstOrDefault(). What happens is that without any query rules defined in SharePoint, the resultTableCollection only contains one ResultTable. In this case FirstOrDefault doesn't matter since there is only one table going to return anyways. However, adding a Query Rule (can be done in Central Administration\Search Service Application\QueryRule) will lead to an additional result table in the resultTableCollection. Now FirstOrDefault matters because it depends on which table is actually default or first. The order actually is not determinable because it's up to SharePoint search to return which result table first.

Under such condition, using resultTableCollection.FirstOrDefault() is not necessary going to give us the search results from the keywordQuery in the code. It could be the results from the Query Rule.

One way to handle this situation is to stop making assumption that resultTableCollection.FirstOrDefault() always return the results from the SearchExecutor keywordQuery, and try to identify the result table that holds the result you wanted. Sometimes you might want the results from the query rule instead. What you can do is to get all the results tables and check their QueryRuleId property value:

- If the results table is from a QueryRule, then the QueryRuleId property will return the Guid of the QueryRule.

- If the results table is from the SearchExecutor keywordQuery results, then the QueryRuleId property will return an empty Guid; i.e. 00000000-0000-0000-0000-000000000000.

This post is a contribution from Charls Tom Jacob, an engineer with the SharePoint Developer Support team

If you are finding it difficult to debug your remote event receiver, most probably you would be using an incorrect connection string to connect to the Microsoft Azure Service Bus. Visual Studio Error List will show

“Cannot register Services/RemoteEventReceiver1.svc on Microsoft Azure Service Bus: The remote server returned an error: (500) Internal Server Error.”

Important point to note here is:

Ref: http://msdn.microsoft.com/en-us/library/office/dn275975(v=office.15).aspx

You can use Microsoft Azure Powershell to setup an Azure Service Bus Namespace as below:

PS C:\> New-AzureSBNamespace rerdebug 'East US' -CreateACSNamespace 1

Which gives you the following output:

Set the value for “Endpoint=” highlighted above as your connection string and you should be good to go!

When connected successfully, you will find the following in the Visual Studio output window:

“Services/RemoteEventReceiver1.svc has been registered on Microsoft Azure Service Bus successfully”

Note: If you find that debugger is properly attached but breakpoints are never hit, make sure that you are performing the action (adding list or list item) in the App Web, not the Host Web. Remote event receivers FAQ

This post is a contribution from Kevin Jacob Kurian, an engineer with the SharePoint Developer Support team

We come across this requirement wherein we would need to utilize REST API calls in SharePoint 2013 workflows. Using the new “Call HTTP web-service action” in SharePoint 2013, we can achieve the same. We could utilized any of the available REST APIs to meet our requirement but in this example, I will show how to create a folder (in a document library) and a list item (in a list) using REST API.

1. I created a Site workflow (even a List workflow should work out)

2. The first Dictionary is the header (Output variable) with the following key/value pairs.

3. Then I created the second Dictionary which is metadata (Output Variable). The SP.Folder type specifies that we are creating a SPFolder utilizing the REST call.

4. The last Dictionary is the parameters (Output variable)

5. The above Server Relative URL gives the relative URL for the document library (“Shared Documents”) along with the new folder name (“Test 2”). In this example, I am creating the folder in a sub-site (“sub”) which requires setting up Workflow elevated privileges shown in Steps 10-13. If we are creating the folder in the same site, then we can avoid setting up the Workflow elevated privileges and by Step 9, our workflow setup is complete.

6. Then we add the Call HTTP web-service with the following details.

7. The REST API call should contain the name of the sub-site, “sub”.

8. Set the RequestHeaders to Variable header.

9. Also set the Request parameters to variable:Parameters.

10. Now we need to set the workflow to run in elevated privileges.

11. Please follow this walk-through blog to set the Workflow elevated privileges, http://msdn.microsoft.com/en-us/library/jj822159.aspx

12. The only place where we will differ is the Permissions Request

<AppPermissionRequests>

<AppPermissionRequest Scope="http://sharepoint/content/sitecollection" Right="FullControl" />

</AppPermissionRequests>

13. Don’t change the above Scope value and keep it the same.

14. The above scopes gives workflow with App Steps privileges at a site-collection level.

15. Once the above steps are completed, our workflow should work fine and we should be able to create the folder in sub-site.

Add-On

a) For creating a list item using the same approach, we need some slight changes.

b) In Step 3 (above), the type of the list item should be specified like:-

c) The type of the List item varies from each list in the site and to get the type value for your list, you would need to browse to this REST url (http://<site-name>/_api/web/lists/getbytitle(‘<listname>’)/items) and get the <category> tag’s term attribute. The below snippet shows my example SPList type:-

d) In Step 4 (above), instead of the ‘ServerRelativeURL’, we would need to specify the list fields and list field values. Since I am targeting a simple list, I just have a ‘Title’ field. The below entries should replace the ‘ServerRelativeURL’.

e) In Step 6 (above), we would need to utilize this particular REST API call:-

f) The remaining steps would be the same for the create folder workflow.

Hope this helps in understanding how REST API calls happen from a SharePoint 2013 workflow.

This post is a contribution from Charls Tom, an engineer with the SharePoint Developer Support team

When you build a Visual Studio Workflow targeting SharePoint 2013, you will see this error if you are using any expression that’s not supported inside a workflow.

The reason for this is that 2013 workflows support only a very limited subset of .NET framework methods. In case you really need to so some operations that are not supported, best workaround is to implement it as a custom REST service method and call it using (HttpSend) where necessary.

Hope this helps!

This post is a contribution from Raghavendra Nanjaiah, an engineer with the SharePoint Developer Support team

What is the issue?

When you try to publish the SharePoint 2010 reusable or list workflow on SharePoint 2013 platform using SharePoint designer 2013 you will get following exception in UI

If you carefully observe the ULS logs

08/22/2014 16:17:53.40          w3wp.exe (0x2610)      0x05D4            SharePoint Foundation      Legacy Workflow Infrastructure           xmfh    Medium           Workflow Compile Failed: Could not find a part of the path 'C:\Users\devapppool\AppData\Local\Temp\cjjkiult.tmp'. b118b19c-3fad-30ad-ac8b-ed8c02395742

Why we face this issue?

During the workflow publishing phase, SharePoint will create couple of temporary files under the temp folder (of the app pool service account). As part of clean-up process w3wp process will delete this files later.

Sometimes, instead of deleting content inside temp folder w3wp process deletes the temp folder. Because of which workflow publishing fails with “Could not find a part of the path”

How to work around this issue?

Create a text file and provide read only access to file. This will stop process from deleting temp folder.

1. Navigate to C:\Users\<service-acct>\AppData\Local\Temp on both the server (WFE1 and WFE2)

2. Create a text file inside the temp folder and in the properties check read-only option.

3. Reset iis /noforce

4. Publish the workflow.

This post is a contribution from Aaron Maio, an engineer with the SharePoint Developer Support team

The article describes how to add custom help for SharePoint sites with out-of-box feature Custom Site Collection Help in SharePoint 2010.

If you have packed your Help files in a CAB file, you can use HCINSTAL.EXE (in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\bin folder) to install your custom help collection.

In SharePoint 2013, HCINSTAL.EXE is discontinued. Instead, you need to install your custom Help Collection files with PowerShell Install-SPHelpCollection.

Install-SPHelpCollection starts actually a timer job to install all help files from a Help CAB file to a hidden site called Product Help Site. You can find the site with URL like http://your-ca-server/sites/Help. The Product Help library in this site contains all help collections installed.

Properties are also changed. Here’s the SharePoint 2010 Help Collection properties

Here’s SharePoint 2013 Help Collection properties:

Noticed that a new property called SharePoint Version is added for SharePoint 2013. The SharePoint Version is set based on the <version> of manifest.xml file in a help CAB file.

NOTE:

If you have an existing Help Collection and it’s <version> in manifest.xml is like this:

The Help files will be installed correctly. However the help won’t show up in SharePoint 2013 sites. You need to change the Help Collection item property SharePoint Version to15 to make it work.

I worked on a support case recently and wanted to share the learning to the community.  The issue was that when we create a SharePoint 2013 Workflow in SharePoint Designer 2013, add a few actions and values in it and save the workflow, part of the values wouldn’t persist in the workflow XOML file.  You can confirm it by closing and reopening the workflow in SharePoint Designer 2013.  Well, it’s not actually any workflow you design that depicts this behavior, but only workflows that is built using a particular incorrect logic.

To give you a better understanding, here are the steps to reproduce the problem.

1. Create a document library in a SharePoint 2013 site and name it “Docs1”.

2. Add two currency columns (actually, any column would do to reproduce this behavior) named “Currency1” and “Currency2”.

3. Open this site in SharePoint Designer 2013.

4. Create a SharePoint 2013 Workflow associated to a list (List Workflow with platform SharePoint 2013 Workflow).  The list in this case would be “Docs1” the document library.

5. Use the below logic in the default stage of the workflow in the designer.

6. Save and close the workflow.  Open it again and you’ll see that the values are persisted.

7. Now create another stage with the following logic.

8. Now, save the workflow again and close it.

9. Reopen the workflow and now you’ll see the values you provided in the conditions are lost in Stage 2.

That’s the repro of the problem. If you look at the logic of the individual stages, you’ll find it doesn’t make sense to actually have a Stage 2. Because both the ‘if’ and ‘else’ branch in Stage 1 of the workflow ends the workflow.

As you know, the new SharePoint 2013 Workflow works declaratively (XOML). The size of the XOML file has a say on how efficiently the workflow runs. In the case of the above workflow, SharePoint parses through the logic of the workflow as well and determines ‘Stage 2’ is actually not needed at all. So, it simply omits the values in it when saving the workflow but leaves ‘Stage 2’ design in the designer (which, presumably is stored in the XOML file just as a reference as not with the actual values). And thus the so called “problem”. Well, this isn’t actually a problem, but it’s the way SharePoint tried to optimize things.

We resolved this by making the ‘if-else’ logic more meaningful as shown below.

After this change, the entire workflow design was persisted as expected.

Though this is something small, I was taken by surprise when this was reported as a problem and was quite impressed by the way SharePoint and SPD 2013 works together to try to ensure it executes actions (and activities in VS Workflows) in an optimized way!

This post is a contribution from Aaron Miao, an engineer with the SharePoint Developer Support team.

For various reasons, people want to change the file extension of an existing item in a document library.  For example, with SharePoint 2007, files with JSON extension in document library can be opened without problems.  However, once you upgrade to SharePoint 2010, you cannot open the file anymore.  You’ll get an error similar to what’s shown below.

An error occurred during the processing of /Shared Documents/test.json.

The page must have a <%@ webservice class=”MyNamespace.MyClass” … %> directive.

In order to be able to see the JSON file content with SharePoint UI, one option is to change the file extension from JSON to TXT.  But you cannot change the name or display name of the file.  This can be accomplished by two methods as shown in the below samples that uses PowerShell.  And of course, you can do the same with SharePoint server OM.

Use SPFile.MoveTo

$site = Get-SPSite "http://yoursite"

$web  = $site.RootWeb

$list = $web.Lists["Shared Documents"]

$item = $list.GetItemById(0)

$file = $item.File

$file.MoveTo($item.ParentList.RootFolder.Url + "/” + ”test.txt")

$file.Update()

Use SPFile.CopyTo

$site = Get-SPSite "http://yoursite"

$web  = $site.RootWeb

$list = $web.Lists["Shared Documents"]

$caml = '

  <Where>

    <Eq>

      <FieldRef Name="File_x0020_Type" />

      <Value Type="Text">json</Value>

    </Eq>

  </Where>

'

$query = new-object Microsoft.SharePoint.SPQuery

$query.Query = $caml

$items = $list.GetItems($query)

foreach($item in $items)

{

      $file = $item.File

      $url = $file.ServerRelativeUrl

      $newurl = $url.replace(".json", ".txt")

      $file.CopyTo($newurl)

}

Hope this was helpful.

This post is a contribution from Balaji Sadasivan, an engineer with the SharePoint Developer Support team.

As most of you are already aware SharePoint stores both the person/group field and the metadata fields as lookup values internally.

SharePoint dynamically creates a stored procedure to store the lookup values in SQL.  The stored procedure accepts a number of parameters from SharePoint to perform these operations.  And when the number of parameters exceeds 2100, it will throw an error.  This limitation of SQL is documented in this TechNet article Maximum Capacity Specifications for SQL Server.

So now the question arises as to how many lookup values can we add before we hit this limitation?

Here’s what my testing so far shows.  By no means is this an authoritative or an official data.

Now we need to note that the SQL limitation is for a list item and not for individual fields.  This means that if you have 2 metadata columns that total values present in both the columns combined cannot exceed approximately 250 values.  This becomes exceedingly complicated when you have multiple types of lookups grouped together and hence you must exercise caution considering these limitations.

This post is a contribution from Pavan Kumar, an engineer with the SharePoint Developer Support team.

As in SharePoint 2007 and 2010, one of the ways to achieve this is to use FeatureStapling.  Below are the steps to be followed to get this working.

Create a SharePoint 2013 Empty project in Visual Studio 2012 and give it a name (e.g., ChangeMySiteMaster).

Provide your MySite Host URL and choose to deploy this as a farm solution.

Add a new Module from Visual Studio 2012 SharePoint item templates to the project.

By default, MySites use mysite15.master as its default master page.  This can be found under 15\TEMPLATE\FEATURES\MySiteMaster\mysite15.master.  Copy this file and add it to the project you created.  Rename it to CustomMySite.master and modify this file per your needs.

Delete Sample.txt available in the Module and edit Elements.xml file such that it looks like this:

<?xml version="1.0" encoding="utf-8"?>

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

  <Module Name="MasterPage" List="116" Url="_catalogs/masterpage" Path="MasterPage" RootWebOnly="TRUE">

    <File Url="CustomMySite.master" Type="GhostableInLibrary"/>

  </Module>

</Elements>

Add a new feature to the project and add a feature event receiver to it.  Ensure that module is added to the feature.

Add below code in FeatureActivated event of EventReceiver.cs.

Add below code in FeatureDeactivating event of EventReceiver.cs.

Create another farm level feature.  Name it as MySiteFarmStapler.  Add a new empty element to the project and name it as ML_ApplyCustomMasterPageStapler.  Add the following markup to the XML.

<?xml version="1.0" encoding="utf-8"?>

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

  <FeatureSiteTemplateAssociation Id=<GUID from EventReceiver.cs>" TemplateName="SPSPERS" />

</Elements>

Add the module to Stapler feature.

Save all the files and deploy.  Login to your personal site and activate the feature from Site collection features.  Personal sites created henceforth will have the new master page applied to it.

This post is a contribution from Raghavendra B Nanjaiah, an engineer with the SharePoint Developer Support team.

Just wanted to publish this post provided the steps to publish a LightSwitch App to SharePoint On-Premises environment.  Hope you will find this useful.

Section 1: Create issuer ID (same as high-trust app)

1. Check if any previously registered SPTrustedSecurityTokenIssue exists.  If there’s a malfunctioning one and if –IsTrustBroker switch was used, it means the bad token issuer might be getting called.  If this is the first time you are configuring high-trust apps then you can skip steps a & b below.

a. Run Get-SPTrustedSecurityTokenIssuer.  If no Azure workflow is configured this command should return empty.  If you get any issuer apart from workflow, run below script to delete it.

b. Remove-SPTrustedSecurityTokenIssuer (pass Id value from output of the above command).

2. Create a new SPTruestedSecurityTokenIssuer by running below script, passing your SharePoint Developer site URL and Cert path (.cer) that you will use to sign the token (you need to create a self-signed cert).  For more information see: http://msdn.microsoft.com/en-us/library/fp179901.aspx.

Take a note of the $issuerId = “447f40c6-99df-4d37-9739-5370102489f7” from the below script.  We’ll be using it later.

param( 

                [Parameter(Mandatory=$true)][string] $TargetSiteUrl,

                [Parameter(Mandatory=$true)][string] $CertPath = $(throw "Usage: ConfigureS2SApp.ps1 <TargetSiteUrl> <Certificate>") 

)

# On error, stop

$ErrorActionPreference = "Stop"

# Add sharepoint snapin

# add-pssnapin microsoft.sharepoint.powershell

function ConfigureS2SApp([string]$TargetSiteUrl, [string]$CertPath)

{

                #write-host "Configuring with parameters $appTitle , $TargetSiteUrl , $CertPath"

                write-host "you passed" $TargetSiteUrl $CertPath -foregroundcolor Green

                $issuerId = "447f40c6-99df-4d37-9739-5370102489f7"

                $spweb = Get-SPWeb $TargetSiteUrl

                $realm = Get-SPAuthenticationRealm -ServiceContext $spweb.Site

                $fullAppIdentifier = $issuerId + '@' + $realm

                $certificate = Get-PfxCertificate $CertPath

                New-SPTrustedSecurityTokenIssuer -Name $issuerId -Certificate $certificate -RegisteredIssuerName $fullAppIdentifier –IsTrustBroker

                #turning off https <optional> this will make our sharepoint site run on http and still work with high trust app.

                $serviceConfig = Get-SPSecurityTokenServiceConfig

                $serviceConfig.AllowOAuthOverHttp = $true

                $serviceConfig.Update()

}

ConfigureS2SApp $TargetSiteUrl $CertPath

# done

write-host "S2S is now configured" -foregroundcolor Green

Section 2: Enable SharePoint on LightSwitch app and publish

1. Right-click the LightSwitch project and go to properties and choose SharePoint tab.

2. Enable SharePoint on the project (this basically adds SharePoint related files to LightSwitch project e.g., SharePointLaunch.aspx etc.,).

3. Right-click on the project and click Publish.

4. Select Provider-hosted in SharePoint options.

5. Select IIS server since we will not be using Azure to host LightSwitch app.

6. Select Create Package on disk from the next screen.

7. Select users must connect using Https option.

8. Choose the appropriate data settings for your LightSwitch app.

9. Select use a certificate for a high-trust configuration and provide the certificate details and issuer ID we generated in Section 1 of this post.

10. Choose the web app where LightSwitch will be hosted and provide Client ID (you can generate your own GUID using Visual Studio or PS).

11. Create app principal by following the below steps in PS.

$clientId = "<Your Client ID>"

$spweb = Get-SPWeb "http://mspx2013"

$realm = Get-SPAuthenticationRealm -ServiceContext $spweb.Site

$fullAppIdentifier = $clientId + '@' + $realm

$appPrincipal = Register-SPAppPrincipal -NameIdentifier $fullAppIdentifier -Site $spweb -DisplayName "SimpleHTApp"

Set-SPAppPrincipalPermission -Site $spweb -AppPrincipal $appPrincipal -Scope Site -Right FullControl

12. The summary screen should look like below.

13. From the published folder, upload the .app file to SharePoint Developer Site.

14. Host the LightSwitch app in different IIS web (e.g., https://localhost:9090).

15. When you click on the SampleLightSwitch app you will be redirected to the actual LightSwitch app that’s hosted in your IIS server.

This post is a contribution from Aaron Miao, an engineer with the SharePoint Developer Support team.

Create a test site

1. We create a SharePoint site collection named http://intranet.contoso.com/sites/testsite/testexternallist.

**It’s good to use a site which does not have lot of stuffs, best would be to create a new team site or blank site.

2. Activate the following site collection features:

     a. SharePoint Server Enterprise Site collection features

     b. SharePoint Server Standard Site collection features

Prepare SQL Database table

**You could use Northwind sample database

3. Create a table in SQL database called TestTable.

4. Add some data to it.

Create an external content type and a list instance using SharePoint Designer 2013

5. Open the test site using SPD 2013 and create an external content type ExternalTestCT (reference if you need it).

6. Create external list using SPD 2013 and choose to create InfoPath forms.

The result should look like this.

7. Verify external list works by browsing to it using SharePoint 2013 UI.

8. Make sure the external list displays data successfully in InfoPath forms.  “View Item” of the list will display an item in InfoPath form like this:

Prepare Visual Studio SharePoint 2013 project

9. Now save the site as template without content using SPD 2013.

10. This will generate a WSP file in your site collection solution gallery.  Download a copy of this WSP and save it to local disk.

Create Visual Studio 2013 project and solution

11. Create a Visual Studio 2013 project of type “SharePoint 2013 – Import Solution Package” and point to the saved WSP.  As a reference, this blog walks through the entire process.

**When there’s a warning about dependencies, click “Yes” to have VS 2012 automatically include all dependencies.

12. Once you are done with these steps, you will have the external list instance, with its schema.  You will also have Modules with all the InfoPath forms and template.xsn.  In addition, you’ll see a PropertyBags module as well.  Your project should look like this:

13. Clean up unnecessary files

       a. Remove ListsExternalList1_pages item

       b. Remove 2 features (3 features are imported.  Retain the first feature you see from the top in the list of features and remove the other 2)     

       c. Make sure the feature includes items: List instances, Modules and PropertyBags.

In the end, your project should look like this:

Details of each file

**Make sure you verify that the external list name is same in the list instance and all the files (schema, module files).  There are lots of places the list name and its URL is used.

14. ExternalList1/Elements.xml:

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

    <ListInstance FeatureId="{00bfea71-9549-43f8-b978-e47e54a10600}" 

                TemplateType="600" 

                Title="ExternalList1" 

                Description="" Url="Lists/ExternalList1" 

                CustomSchema="Files\Lists\ExternalList1\Schema.xml" 

                HyperlinkBaseUrl="http://spdev1505/sites/TestSite" 

                RootWebOnly="FALSE" xmlns="http://schemas.microsoft.com/sharepoint/">

        <DataSource>

            <Property Name="Entity" Value="ExternalTestCT" />

            <Property Name="EntityNamespace" Value="http://spdev1505/sites/testsite" />

            <Property Name="LobSystemInstance" Value="testdb" />

            <Property Name="SpecificFinder" Value="Read Item" />

        </DataSource>

    </ListInstance>

</Elements>

**<DataSource> provides information of the generated BDC model.

15. ExternalList1/Schema.xml:

<List Title="ExternalList1" 

      Direction="none" 

      Url="Lists/ExternalList1" 

      BaseType="0" Type="600" 

      MultipleDataList="FALSE" 

      DontSaveInTemplate="TRUE" 

      DisableGridEditing="TRUE" 

      NoCrawl="TRUE" 

      DisallowContentTypes="TRUE" 

      BrowserFileHandling="permissive" 

      NavigateForFormsPages="TRUE" 

      FolderCreation="FALSE" 

      DisableAttachments="TRUE" 

      Catalog="FALSE" 

      SendToLocation="|" 

      ImageUrl="/_layouts/15/images/itebl.png?rev=23" 

      xmlns:ows="Microsoft SharePoint" 

      xmlns:spctf="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms" 

      xmlns="http://schemas.microsoft.com/sharepoint/">

    <MetaData>

        <Fields>

            <Field DisplayName="BDC Identity" Hidden="FALSE" Name="BdcIdentity" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="BdcIdentity" Type="Text" ReadOnly="TRUE" />

            <Field DisplayName="TextCol" Hidden="FALSE" Name="TextCol" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="TextCol" Type="Text" ReadOnly="TRUE" Required="TRUE" />

            <Field DisplayName="DateCol" Hidden="FALSE" Name="DateCol" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="DateCol" Type="DateTime" />

            <Field DisplayName="BoolCol" Hidden="FALSE" Name="BoolCol" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="BoolCol" Type="Boolean" />

        </Fields>

        <Forms />

        <Views>

            <View DisplayName="ExternalTestCT Read List" DefaultView="TRUE" BaseViewID="1" 

            Type="HTML" MobileView="TRUE" MobileDefaultView="TRUE" ImageUrl="/_layouts/15/images/generic.png?rev=23" 

            XslLink="main.xsl" WebPartZoneID="Main" WebPartOrder="0" Url="Read List.aspx" SetupPath="pages\viewpage.aspx">

                <XslLink>main.xsl</XslLink>

                <Method Name="Read List" />

                <Query>

                    <OrderBy>

                        <FieldRef Name="TextCol" />

                    </OrderBy>

                </Query>

                <ViewFields>

                    <FieldRef Name="TextCol" ListItemMenu="TRUE" LinkToItem="TRUE" />

                    <FieldRef Name="DateCol" />

                    <FieldRef Name="BoolCol" />

                </ViewFields>

                <RowLimit Paged="TRUE">30</RowLimit>

                <Aggregations Value="Off" />

            </View>

        </Views>

    </MetaData>

</List>

**Type=”600” indicates this is an external list.  Fields are defined in the schema.

16. Modules/ListsExternalListItem_/Files/Elements.xml:

17. PropertyBags/Elements.xml:

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

  <PropertyBag Url="Lists/ExternalList1/Item/template.xsn" ParentType="File" RootWebOnly="FALSE" 

               HyperlinkBaseUrl="http://spdev1505/sites/TestSite" 

               AlwaysCreateFolder="TRUE" 

               xmlns="http://schemas.microsoft.com/sharepoint/">

    <Property Name="ipfs_streamhash" Value="WilYbGIFAHARhhugf7kJzQlo447iT2RkT/siF5/CimI=" Type="string" />

    <Property Name="vti_streamschema" Value="66" Type="int" />

  </PropertyBag>

</Elements>

**There are many properties in the file generated originally.  Only the above two are required.  Looks like they are related to InfoPath form activation and file persistence.

In the end, you should see the artifacts like in the VS 2012 project attached to this blog post.

Test the solution

18. Deploy the project to another site.  You may not see the external list in the quick launch.  Navigate to site contents and click the external list.  You should see the list and InfoPath item view form.

19. The view form URL should like like what’s shown below.  Notice that displayifs.aspx is used and not DispForm.aspx.

http://intranet.contoso.com/sites/TestSite/Lists/ExternalList1/Item/displayifs.aspx?ID=__bk410047005600870047004300&Source=http%3A%2F%2Fspdev1505%2Fsites%2FTestSite%2FLists%2FExternalList1%2FRead%2520List%2Easpx&ContentTypeId=0x0&RootFolder=%2Fsites%2FTestSite%2FLists%2FExternalList1

Hope this post was helpful!

This post is a contribution from Charls Tom Jacob, an engineer with the SharePoint Developer Support team.

In this blog, I will describe the steps to deploy a provider hosted app on Windows Azure hosted site (same steps should work for any IIS sites for that matter).  The app will be deployed into SharePoint Online site, whereas the underlying business logic will reside on a separate server.  It could be an on-premise server or a server provided by a hosting company.  For this blog post, I decided to use a site hosted on Azure.

1. Create a provider hosted app project in Visual Studio 2012.

2. Select ACS.

3. Navigate to your App Catalog site collection URL (/_layouts/15/appregnew.aspx).

a. Generate a Client ID and Client Secret.

b. Make sure to give correct values for AppDomain and Redirect URL. This should be corresponding to where you want to host your app web.

4. Publish the App project by specifying the same Redirect URL, Client ID and Client Secret as in the previous step.

5. This gives you the deployable units as below.

a. Rename the .app file to .zip and verify that app manifest contains the correct Client ID.

6. Upload the app to the App Catalog site collection in your SharePoint site.

7. Modify the AppWeb web.config file to include the Client ID and Client Secret as shown below.

8. Deploy the web site to the desired location using any of the publishing methods available.

9. Add the app to one of the sites and launch it.

NOTE: You will run into “The parameter ‘token’ cannot be null or empty string” error if you make a mistake in the Client ID and/or Client Secret or redirect URL.

Hope this walk-through was helpful!

This post is a contribution from Raghavendra B Nanjaiah, an engineer with the SharePoint Developer Support team.

Problem

When you try to add users through the UserGroup.asmx web service (http://localhost/_vti_bin/UserGroup.asmx) in SharePoint 2013 with the sample code below.

sp.UserGroup usrgrpService = new sp.UserGroup();

usrgrpService.Credentials = new System.Net.NetworkCredential("Administrator", "access", "contoso");

usrgrpService.AddUserToGroup("Dev Members", "usera",

"contoso\\usera", "usera@contoso.com", "Notes");

You will successfully add user to the SharePoint group, but if you look at the user permission or try accessing site using this user credentials, you’ll get “Site is not shared with you” message.

Solution

You have to pass user in claims encoded format (e.g., i:0#.w|contoso\chris) in SharePoint 2013.  This is because claims authentication is enabled in the web applications you create by default.

Not that this is something that many don’t know, but we’ve had customers reporting this issue to us and we thought we’ll get this message out!

HTH

This post is a contribution from Raghavendra B Nanjaiah, an engineer with the SharePoint Developer Support team.

First part is to create our code activity and let the Workflow Manager and SharePoint 2013 know about it.

1. In VS 2012, click New Project, Workflow and choose Activity Library.

2. Delete the declarative Activity1.xaml from the solution since we will be creating our own custom code activity.

3. In solution explorer on newly created activity library right click and select add new item -> Workflow -> Code Activity.

4. Decide what data you would like to pass in to custom activity. In my case I am accepting string as InArgument and trying to create new list item based on the input string parameter  (you can also use OutArgument which represents the flow of data out of an activity).

5. Write your activity logic in overridden execute method.

6. Build the Project and sign the code activity assembly.

7. Now, Create a new xml file and name it as AllowedTypes.xml and add the reference of you activity library dll , Namespace and type as shown below ( this basically adds your assembly to whitelist which Workflow service trust and loads. If your assembly is not in whitelist you might receive activity not found exception)

8. Now it's time to deploy our assembly and allowedtypes.xml to the folder from where Workflow manager and SharePoint can read.

* On the Workflow Manager box you have to:

     - Copy activity assembly to following locations:

          > %ProgramFiles%\Workflow Manager\1.0\Workflow\Artifacts

          > %ProgramFiles%\Workflow Manager\1.0\Workflow\WFWebRoot\bin

     - Add your activity class to the white-list

          > Copy AllowedTypes.xml  also to above two locations

     - Restart “Workflow Manager backend” service

* On SharePoint box you have to:

     - Copy activity assembly to SharePoint box and install it in the GAC.

     - Reset IIS

Now, the second part is to create a workflow using custom code activity that we created by following the above steps.

1. Now in the same visual studio solution where you have custom code activity add new SharePoint 2013 Workflow project.

2. From the toolbox drag and drop the custom code activity that we just developed.

3. Right click and deploy the solution to your SharePoint site.

Bingo! Now we have developed and deployed custom code activity Workflow in SharePoint 2013 with Workflow Manager 1.0.

Hope this helps!

I worked on a few issues dealing with this subject recently and I thought I’ll share this out so that it can come handy for you.

If you have developed custom field types and custom rendering template that uses server-side OM to achieve a certain UI behavior or to perform some server-side validation… read on!  Well, if you have not implemented any such thing but still interested to know what’s this all about, be my guest

Scenario #1:

Let’s assume you have created a custom field type [SharePoint 2010: Creating Custom Field Types].  Created a site column using this custom field type.  You then create a custom content type via UI inheriting from the folder content type.  And associated this site column to the custom folder content type.  And then associated this custom folder content type to a list or a document library.

Now, you would expect that whenever you create a new folder using this custom folder content type in a list or document library, you’d see the site column (that was created from the custom field type) available as one of the folder property.  And that you’d be able to type some value in it and save.  Yes, that’s an expected expectation!  But you’d be surprised that though the site column is displayed, when you provide some value to it and hit Save to create the folder, the value you provided for the site column goes off and the folder never gets created!!!

Scenario #2:

Let’s assume you have designed a custom rendering template and exposed a custom rendering control that uses this template.  You have this template tied to a custom list definition you created.  You have some specific logic in terms of how the list items render in display, edit modes.  You would have obviously used the ListFieldIterator control to achieve certain or all parts of your requirements.  In this specific scenario reported to me, there was a logic to change the SPControlMode to Display even with the item is rendered in an edit form.  This logic was a server-side code and it wasn’t working!!!

Apparently, CSR [Client-Side Rendering] was at play here again and due to that server-side code failed to execute.  In SharePoint 2013, the recommended approach to customize rendering of a view or a field type is by using client-side rendering.  You can override the rendering template and do all sort of nice things in a much more neat manner.  Here are some articles to learn more about it.

How to: Customize a field type using client-side rendering

SharePoint 2013: Create custom Geolocation field type with client-side rendering

SharePoint 2013: Customize a list view by using client-side rendering

However, what if your requirement is to keep using the server-side logic for some reason (for e.g., to do some validation)?  This was the exact problem reported to me with the scenario mentioned above.  The solution turned out to be pretty simple.

Browse to the form where the field type is rendered.  Edit the page and you’ll see the form uses a ListFormWebPart to display the fields of the item.  Edit the web part to bring up the web part tool part properties section.  Here you’ll find the “CSR Render Mode” option under “Miscellaneous” section.  Just choose “Server Render (ServerRender)” for the “CSR Render Mode” option and that should address the above scenarios.

The “CSR Render Mode” property can also be set using server OM, CSOM and Windows® PowerShell using ListFormWebPart.CSRRenderMode property.

This post is a contribution from Vitaly Lyamin, an engineer with the SharePoint Developer Support team.

SharePoint 2013 allows users to run sites in SharePoint 2010 mode.  In this scenario, the solution (WSP) deployment needs to be deployed with the “CompatibilityLevel” flag set to “All”  or {14,15}.

When deploying the solution from the Central Administration UI, there’s no option to set the “CompatibilityLevel” flag and therefore the deployment job reverts to using the “SharePointProductVersion” attribute in the solution manifest.  Since the “SharePointProductVersion” attribute can only be set to a single number, solution deployment from CA is limited to using that number for the “CompatibilityLevel” setting.

The suggested method for this type of deployment is to use PowerShell:

Install-SPSolution –Identity Solution.wsp –GACDeployment –CompatibilityLevel {14,15}

Resources:

http://technet.microsoft.com/en-us/library/ee617150.aspx

http://technet.microsoft.com/en-us/library/ff607534.aspx

http://blogs.technet.com/b/mspfe/archive/2013/02/04/planning-deployment-of-farm-solutions-for-sharepoint-2013.aspx

HTH!

This post is a contribution from Charls Tom Jacob, an engineer with the SharePoint Developer Support team.

Scenario:

You have a SharePoint library in which “Require documents to be checked out before they can be edited?” is set to Yes. You have a WorkflowStarting event receiver associated to the list, with the following very basic implementation:

public override void WorkflowStarting(SPWorkflowEventProperties properties)

{

    SPList list = properties.ActivationProperties.List;

    int id = properties.ActivationProperties.ItemId;

    SPListItem currentitem = list.GetItemById(id);

}

Issue:

When the event receiver is triggered, the above code will fail with the following exception while getting the item:

ArgumentException was unhandled by user code: Item does not exist. It may have been deleted by another user.

at Microsoft.SharePoint.SPList.GetItemById(String strId, Int32 id, String strRootFolder, Boolean cacheRowsetAndId, String strViewFields, Boolean bDatesInUtc)

at Microsoft.SharePoint.SPList.GetItemById(Int32 id)

at WorkflowEventTest.EventReceiver1.EventReceiver1.WorkflowStarting(SPWorkflowEventProperties properties)

at Microsoft.SharePoint.Workflow.SPWorkflowEventManager.RunWorkflowEventReceiverHelper(Object receiver, SPUserCodeInfo userCodeInfo, Object properties, SPEventContext context, String receiverData)

at Microsoft.SharePoint.SPEventManager.<>c__DisplayClassc`1.<InvokeEventReceivers>b__6()

at Microsoft.SharePoint.SPSecurity.RunAsUser(SPUserToken userToken, Boolean bResetContext, WaitCallback code, Object param)

Reason:

When “Require documents to be checked out before they can be edited?” is set to Yes, the uploaded item gets exclusively checked out to the user who uploaded it. This means item won’t be viewable/accessible to ANY other user. This is because the workflow starting event is triggered way before the upload process is fully complete. When “Require documents to be checked out ” is Yes, user is presented with an additional page which says “The document was uploaded successfully and is checked out to you. Check that the fields below are correct and that all required fields are filled out. The file will not be accessible to other users until you check in.”

Event receiver executes while the user is presented with this popup screen, and it executes in the context of SHAREPOINT\SYSTEM account and runs into this error.

Solution: Impersonate the user account while accessing the list item.

public override void WorkflowStarting(SPWorkflowEventProperties properties)

{

    base.WorkflowStarting(properties);

    SPUserToken token = properties.ActivationProperties.Web.AllUsers[properties.ActivationProperties.Originator].UserToken;

    SPSite site = new SPSite(properties.ActivationProperties.Web.Url, token);

    SPWeb web = site.OpenWeb();

    SPList list = web.Lists[properties.ActivationProperties.ListId];

    SPListItem item = list.GetItemById(properties.ActivationProperties.ItemId);

}

With the above code, item is accessed using the same user account which was used to upload the document, hence the code succeeds in getting the item.

Hope this information was helpful!

This post is a contribution from Charls Tom Jacob, an engineer with the SharePoint Developer Support team.

This blog is based on a support ticket I handled recently. The requirement was to let anonymous users add items to a SharePoint list/library using client side object model(JavaScript).

Here are the steps needed to implement this.

1. Enable Anonymous access at the Web Application level

Go to SharePoint Central Administration => Application Management, select the Web Application => Authentication Providers, click on the zone, and select Enable anonymous access

2. Now, navigate to the corresponding web site, Site Action => Site Permissions => Anonymous Access.

Configure what anonymous users can access at the site level

3. Break the permission inheritance on the specific list in which you want to allow anonymous users to add items.

Navigate to the list/library settings for the list in which you want to allow Anonymous users to add items:

List Settings => Permissions for this list => Stop Inheriting Permissions, click OK => Anonymous Access

Select Add Items.

4. Enable “AddItem” operation for the client object model for the Web Application. You can run the following code as a console application (equivalent powershell script also should work).

Please do IISRESET after running this code

You can make use of the createListItem() and retrieveListItems() method discussed in the following articles to Add/Get items using the anonymous account:

How to: Retrieve List Items Using JavaScript

http://msdn.microsoft.com/en-us/library/hh185007(v=office.14).aspx

Creating a List Item Using ECMAScript (JavaScript, JScript)

http://msdn.microsoft.com/en-us/library/hh185011(v=office.14).aspx

Note: If you are using a custom layouts page to execute the JS Script, make sure it’s accessible to the anonymous users. Inherit the custom page from UnsecuredLayoutsPageBase with AllowAnonymousAccess set to true.

Anonymous layouts page:

Item created by the anonymous user:

Sample code for this is available for download.

Happy anonymous access!!