Update sharepoint-add-ins-compared-with-sharepoint-solutions.md

fixed numerous broken links & markdown errors

Author: andrewconnell

docs/general-development/sharepoint-add-ins-compared-with-sharepoint-solutions.md

@@ -8,21 +8,19 @@ ms.localizationpriority: high
 
 
 # SharePoint Add-ins compared with SharePoint solutions
+
 Learn about when to develop your SharePoint extension as a SharePoint Add-in and when to develop it as a SharePoint farm solution or a no-code sandboxed solution.
 
 This article compares the use cases of SharePoint Add-ins, farm solutions, and no-code sandboxed solutions (NCSSs).
 
-- New SharePoint Add-ins are self-contained extensions that may include cloud-based logic and data, SharePoint components, and client-side scripts, but not custom managed code that runs on SharePoint servers. They are installed from either the Office Store or an organization add-in catalog, and can be installed on either on-premises farms or Microsoft SharePoint Online. For an overview of SharePoint Add-ins, see [SharePoint Add-ins](../sp-add-ins/sharepoint-add-ins).
-
+- New SharePoint Add-ins are self-contained extensions that may include cloud-based logic and data, SharePoint components, and client-side scripts, but not custom managed code that runs on SharePoint servers. They are installed from either the Office Store or an organization add-in catalog, and can be installed on either on-premises farms or Microsoft SharePoint Online. For an overview of SharePoint Add-ins, see [SharePoint Add-ins](../sp-add-ins/sharepoint-add-ins.md).
 - SharePoint farm solutions are packages of SharePoint components that are uploaded to a farm-wide gallery from where they can be installed. They cannot be distributed through the Office Store, and they cannot be installed on SharePoint Online. They can include custom managed code that runs on the SharePoint farm servers. For more information about the basics of farm solutions, see  [Solutions Overview](/previous-versions/office/developer/sharepoint-2010/aa543214(v=office.14)) and [Farm Solutions in SharePoint 2010](/previous-versions/office/developer/sharepoint-2010/gg575564(v=office.14)).
-
-- NCSSs are also packages of SharePoint components; but they are uploaded to a site collection gallery from where they can be installed. They can be installed to either on-premises farms or to SharePoint Online, but they cannot be distributed through the Office Store. They can include almost the same kinds of descriptive components as SharePoint Add-ins and, like add-ins, they can have JavaScript, but they do not contain custom managed code that runs on the SharePoint servers. Differences in the deployment systems of add-ins and NCSSs make NCSSs a better development option for a short list of scenarios. For information about sandboxed solutions, see  [Sandboxed Solutions in SharePoint 2010](/previous-versions/office/sharepoint-server-2010/ee721992(v=office.14).
+- NCSSs are also packages of SharePoint components; but they are uploaded to a site collection gallery from where they can be installed. They can be installed to either on-premises farms or to SharePoint Online, but they cannot be distributed through the Office Store. They can include almost the same kinds of descriptive components as SharePoint Add-ins and, like add-ins, they can have JavaScript, but they do not contain custom managed code that runs on the SharePoint servers. Differences in the deployment systems of add-ins and NCSSs make NCSSs a better development option for a short list of scenarios. For information about sandboxed solutions, see  [Sandboxed Solutions in SharePoint 2010](/previous-versions/office/developer/sharepoint-2010/ee536577(v=office.14)).
 
 > [!IMPORTANT]
 > While developing sandboxed solutions that contain only declarative markup and JavaScript -- which we call no-code sandboxed solutions (NCSS)-- is still viable, we have deprecated the use of custom managed code within the sandboxed solution. We have introduced the new SharePoint Add-in model as a replacement to those scenarios that required the use of managed code. The add-in model decouples the SharePoint core product from the add-in runtime, and this enables much more flexibility and gives you the ability to run the code in the environment of your choice. We realize that our customers have made investments in coded sandboxed solutions and we will phase them out responsibly. Existing coded sandboxed solutions will continue to work in on-premises SharePoint farms for the foreseeable future. Given the dynamic nature of online services, we will determine support needs for coded sandboxed solutions in SharePoint Online based on customer demand. NCSSs continue to be supported. All future investments will go to making the new SharePoint Add-in model richer and more powerful. Accordingly, we recommend that all new development should use the new add-in model whenever possible. In scenarios where you have to develop a farm solution or coded sandboxed solution, we recommend that you design it so that it can easily evolve toward a more loosely coupled development model.
 
 ## Develop an add-in whenever you can
-<a name="AppWhenYouCan"> </a>
 
 The most important guidance we can give you is to develop a SharePoint Add-in instead of a farm solution or NCSS whenever you can. SharePoint Add-ins have the following advantages over classic solutions:
 
@@ -37,7 +35,6 @@ The most important guidance we can give you is to develop a SharePoint Add-in in
 - Enable you to take advantage of the SharePoint cross-___domain JavaScript library to access SharePoint data. Alternatively, you can use a Microsoft-provided secure token service that is OAuth-compatible or use digital certificates to get authorization to SharePoint data.
 
 ## Design add-ins or NCSSs for end users and design farm solutions for administrators
-<a name="SPAppVsClassic_Overview"> </a>
 
 SharePoint Add-ins and NCSSs use one of the SharePoint client object models or REST endpoints to access SharePoint content and components. These client APIs enable SharePoint extensions that are designed for end users. ("End users" in this context are site-collection administrators, website owners, and website members.) The server object model has additional APIs that enable programmatic extensions of SharePoint management, configuration, and security. These include extensions of Central Administration, custom Windows PowerShell commands, timer jobs, and custom backups. For more information about the kinds of administrative extensions that you can develop, see  [Windows SharePoint Services Administration](/previous-versions/office/developer/sharepoint-2010/ms475931(v=office.14)). These administrative extensions are deployed in SharePoint Features that have farm, web application, or site-collection scope. SharePointfarm solutions are also installed by farm administrators, although add-ins and NCSSs can be installed by tenant and site collection administrators.
 
@@ -46,7 +43,6 @@ The server object model also has APIs for create, read, update, and delete (CRUD
 The client object models and REST endpoints do not duplicate the administrative-oriented APIs of the server object model. Moreover, because neither a SharePoint Add-in nor an NCSS can contain custom code that runs on the SharePoint servers, they cannot call these administrative APIs. In addition, all Features in SharePoint Add-ins must have website scope; and Features in NCSSs have either site collection or website scope. Thus, an administrative-oriented SharePoint extension is not really possible with a SharePoint Add-in or NCSS. So, the second principle, but not an absolute rule, is that add-ins and NCSSs are for end users, and farm solutions are for administrators.
 
 ## Design NCSSs for branding and template-like extensions
-<a name="SPAppVsClassic_Overview"> </a>
 
 You may encounter one of the small number of SharePoint development scenarios for which the add-in model is not well-suited, but which you cannot implement with a farm solution either, perhaps because the solution needs to be installable on SharePoint Online or needs to be installable by a site collection administrator. There are two broad, and overlapping, categories of such scenarios.
 
@@ -62,7 +58,6 @@ You may encounter one of the small number of SharePoint development scenarios fo
 For information about how to expand the possibilities of SharePoint Add-ins, see  [Use add-in event handlers conservatively](#AppEventHandlers) and [Add-ins that create extensions](#ExtensionFactories).
 
 ## Doing things the add-in way
-<a name="Questions"> </a>
 
 As noted earlier, custom code that runs on the SharePoint servers is not allowed in SharePoint Add-ins. This is *not* a significant limitation. It simply means that your custom business logic moves either "down" to the client device or "up" to the cloud. In either case, you can use the [SharePoint REST/OData service](/previous-versions/office/developer/sharepoint-2010/ff521587(v=office.14)) to accessSharePoint sites, lists, and other data. You can also remotely access SharePoint data through the [SharePoint JavaScript, Silverlight, or .NET Framework client object models](/previous-versions/office/developer/sharepoint-2010/ee537247(v=office.14)). Finally, on Windows Phones, you can access SharePoint through the SharePointWindows Phone object model. For more information about the various sets of APIs in SharePoint, see  [Choose the right API set in SharePoint](choose-the-right-api-set-in-sharepoint.md).
 
@@ -72,22 +67,21 @@ The following table lists the SharePoint components that cannot be deployed in a
 
 |**If you want the functionality of ...**|**... try these approaches.**|
 |:-----|:-----|
-|Custom web parts  <br/> |A SharePoint Add-in can have remote pages that contain custom web parts. Another option is to expose a page from a remote web application in an add-in part on a SharePoint site page. The remote page can have basically the same UI controls and functionality as a web part. For more information, see  [Create add-in parts to install with your SharePoint Add-in](../sp-add-ins/create-add-in-parts-to-install-with-your-sharepoint-add-in).  <br/> |
-|Event receivers and Feature receivers  <br/> |A SharePoint Add-in can contain functionally equivalent remote event receivers. For more information, see  [Handle events in SharePoint Add-ins](../sp-add-ins/handle-events-in-sharepoint-add-ins).  <br/> |
-|Custom field (column) types  <br/> |An add-in can deploy a new field (column) that is based on one of the  [existing field types](/dotnet/api/microsoft.sharepoint.spfieldtype). The  [Calculated](/dotnet/api/microsoft.sharepoint.spfieldcalculated) and [Computed](/dotnet/api/microsoft.sharepoint.spfieldcomputed) field types are especially flexible. Another option is to present your data in a remote webpage by using customized controls or grids. <br/> |
-|Custom web services built on the SharePoint  [Service Application Framework](/previous-versions/office/developer/sharepoint-2010/ee536263(v=office.14)) <br/> |You can develop your custom web services as remote services.  <br/> |
-|Application pages  <br/> |A SharePoint Add-in can include remote webpages that are available from every website on which the add-in is installed. An add-in can also use any of the built-in SharePoint web parts on site pages.  <br/> |
+|Custom web parts  <br/> |A SharePoint Add-in can have remote pages that contain custom web parts. Another option is to expose a page from a remote web application in an add-in part on a SharePoint site page. The remote page can have basically the same UI controls and functionality as a web part. For more information, see  [Create add-in parts to install with your SharePoint Add-in](../sp-add-ins/create-add-in-parts-to-install-with-your-sharepoint-add-in.md).|
+|Event receivers and Feature receivers|A SharePoint Add-in can contain functionally equivalent remote event receivers. For more information, see  [Handle events in SharePoint Add-ins](../sp-add-ins/handle-events-in-sharepoint-add-ins.md).|
+|Custom field (column) types|An add-in can deploy a new field (column) that is based on one of the  [existing field types](/previous-versions/office/developer/sharepoint2003/dd585363(v=office.11)). The  [Calculated](/dotnet/api/microsoft.sharepoint.spfieldcalculated) and [Computed](/dotnet/api/microsoft.sharepoint.spfieldcomputed) field types are especially flexible. Another option is to present your data in a remote webpage by using customized controls or grids. |
+|Custom web services built on the SharePoint [Service Application Framework](/previous-versions/office/developer/sharepoint-2010/ee536263(v=office.14))|You can develop your custom web services as remote services.|
+|Application pages |A SharePoint Add-in can include remote webpages that are available from every website on which the add-in is installed. An add-in can also use any of the built-in SharePoint web parts on site pages.|
 
 Some SharePoint components, listed below, are used in end-user scenarios, but have no equivalents in the SharePoint Add-in model, and cannot be deployed in NCSSs. For these, you must use farm solutions.
 
 - **Custom site definitions** But custom WebTemplates, which are functionally similar to site definitions, are available in both NCSSs and SharePoint Add-ins. For more information, see [Working with Site Templates and Definitions](/previous-versions/office/developer/sharepoint-2010/ms434313(v=office.14)).
 - **Delegate controls** For more information, see [Delegate Control (Control Templatization)](/previous-versions/office/developer/sharepoint-2010/ms463169(v=office.14)).
 - **Custom themes**
 - **Custom action groups and custom action hiding**
-- **User controls (.ascx files)** No scenario actually requires these.
+- **User controls (\*.ascx files)** No scenario actually requires these.
 
 ### Use add-in event handlers conservatively
-<a name="AppEventHandlers"> </a>
 
 You can overcome some of the limitations of SharePoint Add-ins by creating handlers for the add-in installed, add-in updated, and add-in uninstalling events. These handlers are web services that are hosted on web servers outside the SharePoint farm, possibly in the cloud. They can use the SharePoint client object model, or the REST APIs, to perform CRUD operations on SharePoint components, including components in the host web. In theory, you could use such handlers to overcome some deployment restrictions in the **Branding** and **Template-like extensions** items, discussed earlier. However, we recommend that you use such handlers only as a last resort, when there is no other way to give customers the functionality your use case requires. When deciding whether to create a handler, consider the following:
 
@@ -97,15 +91,13 @@ You can overcome some of the limitations of SharePoint Add-ins by creating handl
 - There are some critical best practices that must be followed in creating add-in event handlers. Your code must include rollback logic to undo everything it has done if it encounters an error. It must also alert the SharePoint infrastructure of the error, so that the infrastructure can roll back everything that it has done.
 - Add-in event handlers are not possible with the type of SharePoint Add-in known as SharePoint-hosted.
 
-For more information about add-in event handlers, see the SDK node  [Handle events in SharePoint Add-ins](../sp-add-ins/handle-events-in-sharepoint-add-ins). For information about rollback logic, see the **Add rollback logic to the handler** section of the topic [Create a handler for the update event in SharePoint Add-ins](../sp-add-ins/create-a-handler-for-the-update-event-in-sharepoint-add-ins) The latter topic is written in the context of the add-in updated event, but the basic principles apply to all add-in event handlers.
+For more information about add-in event handlers, see the SDK node  [Handle events in SharePoint Add-ins](../sp-add-ins/handle-events-in-sharepoint-add-ins.md). For information about rollback logic, see the **Add rollback logic to the handler** section of the topic [Create a handler for the update event in SharePoint Add-ins](../sp-add-ins/create-a-handler-for-the-update-event-in-sharepoint-add-ins.md) The latter topic is written in the context of the add-in updated event, but the basic principles apply to all add-in event handlers.
 
 ### Add-ins that create extensions
-<a name="ExtensionFactories"> </a>
 
 Another way to use the SharePoint client object model -- or its REST APIs -- to resolve component deployment issues with SharePoint Add-ins, is to have CRUD code inside the add-in itself, instead of in an add-in event handler. The add-in then becomes a kind of factory for a type of custom extension. For example, a SharePoint-hosted add-in could use the SharePointJavaScript object model to perform deployment and other CRUD operations on the host web or elsewhere in the tenancy or web application. For another example, see the **Quick introduction to remote provisioning** section of [Site provisioning techniques and remote provisioning in SharePoint](/archive/blogs/vesku/site-provisioning-techniques-and-remote-provisioning-in-sharepoint-2013), which describes how a provider-hosted SharePoint Add-in is used to provide subweb provisioning a lot like SharePoint's in-the-box subweb provisioning. There is, however, a lot of wheel-reinvention, and hence a lot of work in creating a factory SharePoint Add-in. In addition, this kind of add-in cannot be sold through the Office Store because the add-in requires Full Control of the host web.
 
 ## See also
-<a name="bk_addresources"> </a>
 
 - [Programming models in SharePoint](programming-models-in-sharepoint.md)
 - [Using Solutions in SharePoint Foundation](https://msdn.microsoft.com/library/0da0518c-24eb-48e0-89bd-21282fdeef94%28Office.15%29.aspx)