我目前正在尝试学习如何构建应用程序添加到SharePoint中以扩展其功能，在经历了大量的困惑和阅读了所有关于SharePoint加载项的内容后，我在the GitHub page上遇到了这个：
SharePoint外接程序模型被视为用于扩展SharePoint用户界面的旧选项。有关将来经过验证的用于扩展SharePoint Online的选项，请参阅SharePoint Framework文档和SharePoint Framework示例。可能的后端服务应使用基于Azure Active Directly的注册和相关应用程序模型。
在进入SharePoint框架后，我还发现了以下内容：
过去，开发人员将Web部件创建为安装在云服务器上的完全信任C#程序集。
然而，当前的开发模式通常涉及在浏览器中运行的JavaScript，对SharePoint和Microsoft 365后端工作负载进行REST API调用。C#程序集在这个世界上不起作用。开发人员需要一种新的开发模式。
SharePoint框架是SharePoint开发的下一个发展方向。
所以我的问题是，为什么C#程序集不能在那个世界工作，作为SharePoint开发的新手，我应该把注意力完全集中在SharePoint框架上吗？
我试着在谷歌上搜索我的问题，但我有点迷失/被信息淹没，不确定什么是遗产，什么不是遗产，什么是好的实践。I did read this similar post from 2 years ago but I'm still a little confused and curious if anything has changed in those 2 years.
1条答案
按热度按时间nkoocmlb1#
我开发SharePoint解决方案已经有9年了，从SharePoint 2010和SharePoint 2013上的服务器解决方案开始，5年前主要转向使用SharePoint框架（SPFx）的完整SharePoint Online。
为SharePoint 2013创建了加载项以隔离（范围更大）的开发，因为它们能够独立于部署它们的站点。它们还与SharePoint应用商店一起创建，为开发人员提供了一个可以上传其开发的市场（并最终赚钱）。由于人们习惯于使用服务器端技术进行开发（C#和ASP.NET），外接程序是允许服务器代码同时向外部代码开放公司服务器的完美解决方案。
自从SharePoint Online和现代体验的创造（从完整的www.example.com到ReactJS的页面的彻底检修ASP.net）以来，引入了一种新的开发方法：SharePoint框架。它是完整的前端（编译成HTML/JS/CSS和声明性文件，通常用于SharePoint解决方案的配置，......），并实际上取代了SharePoint加载项框架，使前端开发发生了重大转变。
虽然我知道一些公司仍然使用和创建SharePoint加载项，但我相信他们中的大多数人这样做是出于以下两个原因之一：
1.与旧农场或经典经验兼容的必要性（因此为遗留页面）
1.开发人员团队知道这种方法，而且它很有效。
作为一名新的开发人员，您需要考虑的唯一原因是您将为哪些场进行开发。如果您选择SharePoint Online，我的收获是直接选择SharePoint框架。
另一个有趣的考虑是微软对两者的热爱。当插件被完全遗忘，永远不会移动时，SharePoint框架打算与团队和现在的Viva一起飞行。它现在能够承载SharePoint、Outlook、团队、Viva的解决方案，我相信M365 Office的其余部分（Word/Excel/PowerPoint）（有待验证）。
请注意，一些应用程序（使用外部服务、后端流程、计划任务、事件接收器...）将需要使用后端，后端可能采用Azure Web App或Azure功能的形式（如果您希望保持完整的Microsoft，但没有人强迫您）。
为了最终回答你的问题
为什么C#程序集不能在那个世界工作，作为一个sharepoint开发的新手，我应该把注意力完全集中在Sharepoint框架上吗？
您可以开发用C#生成、托管在服务器或云中的接口，并使用SPFx或加载项框架打包解决方案并将其部署在SharePoint上。但是，创建加载项框架是出于特定原因，然后再为今天的结构创建SPFx（云/前端），并允许更多样化的部署选项，更加集成到M365生态系统中。我相信这是您应该投入时间和精力的地方。对于C#/React/Frontend主题，虽然我不打算在这里提出这个争论，但我只想说Microsoft使用SPFx使前端（特别是React）变得更容易，SPFx是最受支持/详细/文档化的解决方案。