Hurry up: Deprecation and end of life for SharePoint Add-Ins & Workflows
In 2012 Microsoft introduced a new development model for SharePoint called "SharePoint Add-In". The goal of the new development approach was to extract custom server side code from SharePoint Server. Because the server side code of classic custom SharePoint Server extensions, like WebParts, Event Receiver or MasterPages with code-behind, are running directly within the SharePoint IIS worker process (w3wp). This means when a custom server side extension throws an exception the whole SharePoint server w3wp process is affected. In such a case the SharePoint page cannot be displayed and the user is frustrated. To mitigate such fatal errors Microsoft tried to move custom code to a separate w3wp process isolated from the SharePoint process. The first approach was the Sandboxed Solutions:
Sandboxed solutions are Microsoft SharePoint Foundation features that are deployed into a partially trusted environment referred to as the sandbox. The sandbox is designed to bring greater stability to a SharePoint farm by restricting actions that could cause problems with performance, security, or other areas. This stability is achieved by limiting the functionality accessible to custom code solutions through the use of code access security (CAS) policies and by restricting access to portions of the object model.
Unfortunately this model is very complex and needs a lot of configuration and considerations and so the most of the SharePoint developers ignored this new development model. More information about Sandboxed solutions see: Chapter 4: Sandboxed Solutions (Inside SharePoint 2010) Announcement about the deprecation: Deprecation of Custom Code in Sandboxed Solutions
SharePoint Add-Ins
After the Sandboxed Solutions Microsoft introduced in SharePoint Server 2013 the SharePoint Add-In model. The goal of this model is to separate customs code from SharePoint Server, too.
The SharePoint Add-In model is a development model for SharePoint Online and SharePoint 2013/2016 on-premises. The main goal of this model is to make developers able of customizing and extending SharePoint sites without the need of having full trust access to the target farm, being able to work remotely with client-side code, which is based on the Client Side Object Model (CSOM) and the REST API of SharePoint.
This development model was used by many developers and the fact that companies or individual developers can publish Apps to an SharePoint Marketplaces engaged developers to use this Add-In model (Me too 😉 I published an Add-In to show address data form a SharePoint list in a Bing Map). More information about the Add-In model follow: SharePoint Add-ins
End of life 😨
But now its time to say good bye to the SharePoint Add-In model. The Add-In model has some technical issues and based on iframe embedding. Now it is time to modernize and to clean-up the existing technical stack. SharePoint Add-Ins come in two flavors: SharePoint hosted Add-Ins and provider hosted Add-Ins, both of which are effected by this retirement. All existing Add-In apps should be migrated to SharePoint Framework Solutions (SPFx). The deprecation of the SharePoint Add-In was announced in late 2013 already. The official end of life is April 2026. Here are the timeframe:
- November 2023: Announced SharePoint Add-in and Azure (Entra) ACS retirement
- March 2024: Stop accepting new Add-In submissions for the App Store
- July 2024: Apps from Store cannot be installed
- November 2024: New Tenants cannot use any Add-Ins and Azure ACS
- April 2026: Add-Ins, Azure ACS and SharePoint 2013 Workflows stops working.
How to prepare?
The Microsoft 365 Assessment Tool helps you identify and evaluate the SharePoint Add-In and Azure ACS usage for your tenant by providing you the usage data of SharePoint Add-Ins and Azure ACS principals, and generating a Power BI report to help you understand the collected information.
Kommentare