SharePoint 2013: Debug your SharePoint App

In SharePoint 2013 app development, you need to run the app from visual studio to debug. However as you debug and you need to make some changes in html or JavaScript, you might wonder that you need to stop debugging, make changes and redeploy the app again. But there’s simplest solution exists.

Unproductive Approach

You might be aware of the following steps which might take long time to debug and make changes:

1. Run the app from Visual Studio in debug mode (with F5).
2. Debug your JavaScript and you’ve found you need to make changes
3. Stop the debug and make changes
4. Rerun the app from Visual Studio with F5

But there’s simplest approach exists for debugging as described next.

 

Productive Approach

You may not know that you don’t need to stop debugging to make changes. You can make changes while the app is running and then refresh the page in the browser. You will get your changes on refreshing/reloading the page. So the new steps are:

1. Run the app from Visual Studio in debug mode (with F5).
2. Debug your javascript and you’ve found you need to make changes
3. Make those changes in Visual Studio without stopping the app.
4. Refresh the page in Browser, you will get the changes (HTML, JavaScript) immediately.

 

Conclusion

Using the second (productive approach) approach, you can develop and debug faster. However, if you make any setting changes like feature changes or appmanifest changes, you need to stop debugging and rerun again.

SharePoint: Too much customization is not good for health

SharePoint allows developer/architect to customize it’s power in numerous ways. You can write event receivers, timer jobs, webparts, application pages and so on. But what I’ve found with my years of experience in working with SharePoint is that sometimes developers/architects make too much customization which is not good from maintenance point of view.

If you are senior SharePoint developer or architect or you have the responsibility to design a solution for SharePoint, first focus on out-of-the-box way to solve the problems. If possible, try to compromise features talking to clients.

Real world Example

Let’s consider a simple example. You have a database which is used by other LOB systems. SharePoint reads and writes data to the database and then other LOB systems (like SAP or some custom applications) use (only read) the data in the database for it’s own use.

Now client requirement is to show the data in the database as SharePoint list so that clients get the feelings that the tables in the database are kind of List in the SharePoint. Now what options do you have? I think we have two options:

• Option 1: Use Business Connectivity Service to show Database tables as SharePoint list
• Option 2: Create custom SharePoint list and then write event receivers to synchronize data between database and List.

Different architect/developer under different circumstances, may use first option or second. But the first option is more out-of-the-box way of implementing the requirements. However some situations demand the second option where you need to  write custom code and need to sync data between SharePoint list and table in database manually. So as an architect/developer I would prefer the first option using Business Connectivity Service. If I need to choose second option then I should have explanation why I need to use second option. The explanation might be Business Connectivity Service has some limitations that we need to overcome with second option, or the requirements are too complex to implement with Business Connectivity Service.

 

But Why?

Now you may ask why it’s matter if I do more customization (I would prefer to say unnecessary customization). I bet it’s matter. The more customization you do, the more difficult to manage codebase, more time to develop, more possible to generate more bugs, more difficult to upgrade to newer version of SharePoint and many more. SharePoint is a rich application framework and we need to utilize it in best possible ways.

 

conclusion

The idea I wanted to share here not to say that you should not do any customization rather make sure your customization really needed. If you do unnecessary customization then you might paving the way for more customizations (maybe for error fixing or features related to customizations). As I read somewhere, “A single bad developer creates job for more developers”. Let’s not create more customizations by an unnecessary customizations.

SharePoint Tips: Iterating through All the webs in the site

Sometimes we need to process all webs in a site collection, as you want to do some quick fixes in the web. Few weeks back my manager asked me to do some fixes in the list items exists in all the webs in the site collection. There were about 30,000 webs in the site collection and I was looking for some kind of script that will be efficient. The usual way of looping through all webs might be using some recursive way, as shown below.

//Starting point
public void ProcessAllWeb(SPSite site)
{
    using (var web = site.RootWeb)
    {
        ProcessWebRecursive(web);
    }

}

//Recursive method
private static void ProcessWebRecursive(SPWeb web)
{
    //do some processing
    //web.Lists["listName"].ItemCount

    foreach (SPWeb subWeb in web.Webs)
    {
        using (subWeb)
        {
            ProcessWebRecursive(subWeb);            
        }
    }

}

Code Snippet 1: Recursive way of processing all webs in the site collection (Not optimized)

In the recursive way of processing all webs, there will be more than one SPWeb instance alive in memory. In the above code snippet, when the method ProcessAllWeb is invoked it’ll call the recursive method ProcessWebRecursive. The recursive method will keep calling the subwebs while keeping the parent web alive.

 

While I was writing the code, I was wonder if there’s any way of processing only one web non-recursively. So my intention was to open only one web in memory at once. And then I found it. You can get all web Url(including all subwebs at all level) using SPSite.AllWebs.Names. The following code snippet shows the efficient way of processing all webs in the site collection:

public void ProcessAllWeb(SPSite site)
{
    string[] allWebUrls = site.AllWebs.Names;
    foreach (string webUrl in allWebUrls)
    {
        using (SPWeb web = site.OpenWeb(webUrl))
        {
            //process web
        }
    }
}

Code Snippet 2: Process all webs one by one (Optimized for large number of webs)

Using the code snippet shown in figure 2, you just open one web at a time in memory for processing. The trick here is ‘SPSite.AllWebs.Names’ which will return all the (I mean it!) subwebs (including children and their children and so on) as a result. If you have thousands of webs under a site collection (and if it’s production), you should care about performance issue.

SharePoint Tips: List.ItemCount vs List.Items.Count

If you need to know the total items in the list, how do you write code? The usual way to write code is shown below:

var itemCount = list.Items.Count;

Code Snippet 1: Usual (not suggested) way to get items count
However this will fetch all the records from database and apply the count in memory.

SharePoint object model provides an easiest way to find the items count without fetching all records and you can use the following code snippet to do so:

var itemCount = list.ItemCount;

Code Snippet 2: Suggested way to get items count

SharePoint Tips: Object Mode provides Built-in Field and Content type Ids

Sometimes we need to access SharePoint built-in fields from list. You may find code to access list item value as shown below:

listItem["Title"] = "value";

Code Snippet 1: Usual approach

 

The title field is SharePoint built-in field and you don’t need to hard-code the field name . SharePoint Object Model provides a class ‘SPBuiltInFieldId'’ where you can find most of the SharePoint built-in field’s IDs. So you can write the above code snippet as shown below:

listItem[SPBuiltInFieldId.Title] = "value";

Code snippet 2: Suggested approach to access built-in fields

 

The class ‘SPBuiltInFieldId’ also provides many built-in fields Ids like ‘created by’ (known as owner), modified by etc.

Similarly you can get built-in content type Ids using the class ‘SPBuiltInContentTypeId’. I would recommend you to use these classes to access built-in fields and content types.