Why I Don't Recommend Using Custom .NET Code in Most SharePoint Projects

Introduction

Modifying SharePoint with custom .NET code is a powerful tool indeed, allowing the auto generation and customization of SharePoint sites and toolsets to a deep degree.  However, in practical terms, I have yet to find a system in the 8 years and numerous clients/projects I have worked on that I would recommend this approach.  Why?

Disclaimer

IF you have a full time dedicated SharePoint support team in your organization that includes a SharePoint farm administrator, various SharePoint experts in each of the specializations (Design, Business Intelligence, Architecture, Business Analysis) then the long term hiring and usage of a SharePoint Developer with deep experience will pay dividends for you.  The problem being of course, this does not represent the majority of SharePoint clients and projects, at least in my experience of 14 years in the field, starting with coding .NET followed by deep SharePoint consultation since SharePoint 2007.

The SharePoint Complexity Stack

One of the key values of SharePoint is its ability to adapt over time as both understanding of system capability and client needs evolve.  It is not a static platform where, once configuration is done, it will typically continue to serve your needs without assessment and further configuration over time.  In fact, its adaptability is one of its key strengths. 


Whenever I have a project upcoming that I need to do an assessment on, I consider the SharePoint complexity stack.  It starts with the simplest to configure and maintain components, and then, as business needs and assessment of current practices inform, we add complexity only where needed and required to meet those requirements.  The stack, from simplest to most complex, follows.

Client Level Configuration

A surprising amount of a typical SharePoint project can be successfully completed using only the SharePoint client.  Custom lists, binding and relating lists, pages, document libraries, content types, views, filtered views, minor look and feel modifications, built in workflows, SSRS report exposure can all be completed without any toolset beyond the SharePoint client.


If a SharePoint project can be completed that is entirely generated using only the client level tools, you not only have a project that is rapid to develop, you have a project that, and this is key, is client maintainable after the project has been released.  The clients will require some basic SharePoint training on permissions, lists and page content updates, but this is well within the range of many client users and training for this specific skillset is widely offered.


Even a project that has other customizations that go deeper in the complexity stack benefit from having as much as possible accessible and maintainable through the SharePoint client.

SharePoint Designer Based Configuration

Once the client based toolset is exhausted, and business requirements force deeper functional needs, the next step in complexity is to use designer.  The typical areas I use designer for are deeper custom workflows that are not "out of the box" level workflows, and the generation of custom look and feel interfaces for various elements (master pages, custom css code), and customization of SharePoint form control behaviour, particularly the forms associated with custom lists that need to behave in a very specific way (get different data from different users, cascading drop down lists, data sequence enforcement).


SharePoint Designer 2013 is forward compatible with SharePoint 2016 so is still a valuable toolset to know and understand.


Even with this toolset at hand, we still continue to focus on having as much of the system as possible end user maintainable through the SharePoint client interface.  That way, changing data needs and requirements can be handled by experienced end users without needing external expertise or expensive updates to the system.

InfoPath and Custom Web Forms

In some cases, the interface with data required by SharePoint for client usage requires multiple SharePoint based data sources and dynamic forms that change depending on the prior field web control selection of clients (the form provides a different question depending on the result of the prior question).  While much of this can be accomplished with the form customization tools within Designer, InfoPath is also a valid choice for creating these complex forms and is fully supported up to SharePoint 2016. 


InfoPath however is typically fairly intimidating for end users, setting up and configuring data connections has gotten to the point where you require real technical expertise, the views and conditional components of the forms are beyond most end users capability, so an InfoPath forms based system needs to meet requirements and be mostly static after release to the clients, unless they plan to have a long term InfoPath forms expert at their disposal. 


And InfoPath can be tricky to deploy between multiple environments.  So, yes, if there is no way to accomplish functionality with the first two toolsets available in the technology stack, InfoPath is a valid choice.  But it is not typically end user maintainable.

SharePoint Designer and Central Administration Configuration

Certain SharePoint customizations require components to be configured at both the designer and SharePoint Central Administration level.  A typical example of this is the Business Data Connectivity Service and Secure Store Service.  If we want to surface data within SharePoint from one or more external SQL Server based data sources, then this is the best option.  This requires more coordination between the SharePoint farm administrator than simply turning off and on features, and deeper knowledge of both Designer and SharePoint Central Admin.  Customizing and using the many services provided by SharePoint can meet business needs in many circumstances, but the deep knowledge and coordination required between the Client/Designer/Central admin components does add complexity.

JQuery based SPServices

Here is where the SharePoint customizations available through .NET start to overlap with the capabilities provided by the SPServices toolset.  SPServices is a rich client based set of components that allows the generation of lists and libraries, along with related components, rich web form based interactions, and completely custom web forms that enhance or allow new functionality over those available in the client interface.  One such example is on this blog:


Adding a User to Multiple Groups


The key advantage I see in using SPServices over custom .NET based code is that the web page functionality is all client side, and, other than the initial download of the Jscript libraries when the user first encounters the functionality, has no effect on the efficient performance of the SharePoint Server itself.  No need to worry about memory leaks, sandboxing, testing customizations on every SharePoint service update done on the server side.  Optimizing a SharePoint Farm to serve tens of thousands of clients is difficult enough without adding the additional considerations of the wide scale custom code deployment.

Customization using .NET Based Modifications

Extremely precise or detailed business requirements may require the time, effort, and expertise necessary to develop custom .NET code.  But before any client or project should go down this path, there are three key considerations:

Expertise Availability

A deeply experienced .NET developer already has a number of employment options and, if their resume has a number of successful large based projects on it, they typically do not have trouble finding work.  SharePoint can be tricky and adds multiple additional layers of complexity to an already deep and complex .NET framework.  And, in addition to learning the new toolsets and deployment options of working with SharePoint, the developer needs a deep understanding of the SharePoint client model, its capabilities, and its restrictions.  It is not surprising that many .NET developers choose to stay as strictly.NET developers, and only a small portion end up being SharePoint developers (in my experience).  If you do manage to find an experienced SharePoint developer who has both at least 5 years foundational skill in .net, and at least 3 years experience in creating customizations for SharePoint using .NET (the minimum I would recommend to "hit the ground running"), then it is most likely going to be expensive.

Maintainability and Migration

Unless, as suggested before, you hire a full time SharePoint developer to both build and update your .NET based customizations in your company/institution, then the majority of what they build is not going to be able to evolve in a significant way over time, a key component of SharePoint's value.  And, when you decide to upgrade to the next version of SharePoint, it will take significantly more expertise to migrate and test these customizations to the new platform than any of the other four customization options available to us.  I have seen reasonably well developed .NET SharePoint based customizations completely abandoned due to the underestimation of the complexity of version migrations, and have seen .NET based customizations completely re-done using the other approaches outlined above because the cost of recreating in the new platform was too prohibitive.

Is SharePoint the Best Choice?

If you do have a system that requires the deep customizations only available through the .NET framework, then the final question you need to ask is, is SharePoint even necessary here?  If you need custom forms to integrate with data schemas that are more complex than provided in SharePoint lists, if you need to integrate data from multiple data sources and provide that data in very specific ways to the client, then would the .NET framework itself meet those needs?  The .NET framework provides rich interface with the various components of office and can allow completely controlled and custom interfaces with that data to meet very restrictive client needs.  And includes workflow capabilities as well.


It is also possible to have the custom .NET developed components linked to SharePoint by sharing data sources between the two, where simplified views of the data are provided by the Business Connectivity Services, reports and dashboards are provided by the Business Intelligence Services available with SharePoint, but the complex data interactions are provided by completely independently developed .NET components. There are even tools that allow you to create an independent .NET application that appears to the end users to be a part of SharePoint creating a seamless experience.


In other words, we have lots of options for creating deep custom applications that meet business requirements that do not require using the SharePoint object model and deep knowledge necessary to create true SharePoint development code based modifications.  If we can keep the system simpler to maintain over time, particularly when considering the farm level implications of custom code, then keeping the .NET customizations and SharePoint as separate as possible is the best choice to make.

Conclusion

I am sure there are SharePoint development teams out there with deep expertise and established deployment and update processes that feel I am overstating the barriers to developing within the SharePoint object model with .NET framework based code.  And I have no argument with that, if you have the expertise and full support of your enterprise, then by all means, fully leverage those capabilities.


However, within my experience of companies using and wanting to leverage SharePoint, the costs and issues outlined above with .NET framework SharePoint based customizations is simply too high.  I believe that, if you do detailed client driven requirements analysis of needs, and then work through the complexity stack outlined above to see how the functionality will be achieved, then in the majority of cases, you won't need code based customizations, or the additional complexity, overhead, and maintenance challenges associated with them.