'Manifest not found for component id' error when loading Teams Tab built with SharePoint Framework
So you’ve built a web part using SharePoint Framework and want to expose it in Teams as a tab or a personal app. Unfortunately, all you see is an error. What’s wrong?
More than just web parts
Since SharePoint Framework v1.7.0, we can expose web parts beyond SharePoint. If you choose to, you can expose the exact same web part as a Teams tab or a personal app. This is great for several reasons.
First of all, it allows you to expose web parts to other experiences. I mentioned Teams already. Over the past few weeks, we’ve seen a huge uptake in Teams usage. As the current situation forces many organizations to work remotely, Teams become the operating system of their employees. This is where they start their day and spend a big part of their day. Bringing the necessary information to where people already are, allows them to stay focused and productive. But Teams aren’t the only place where you can expose your SharePoint Framework web parts. Recently Microsoft announced that you can also expose web parts in Office applications as add-ins. Right now it’s limited to Outlook on the web but in the future, you can expect that SPFx web parts will be omnipresent.
The added benefit of the fact that you can expose web parts beyond SharePoint is significantly lowered development and maintenance effort. Rather than building and maintaining a number of separate solutions, you only build one and you expose it everywhere. Here is your ROI.
Expose SharePoint Framework web parts beyond SharePoint
When exposing SharePoint Framework web parts was introduced initially, you had to manually build and maintain a Teams app manifest for your web parts. Nowadays, you can choose to have the Teams manifest generated for you automatically. All you need to do is to enable exposing your web part in other platforms in the web part manifest:
When you specify that you want your web part to be exposed to Teams, after deploying your SharePoint Framework package to the app catalog, you will see the Sync to Teams button enabled for your solution.
That’s it. After you click that button, SharePoint will automatically generate the necessary manifest for all web parts that should be exposed to Teams, include the icons and wrap it in a Teams app package and deploy it to Teams.
But there is one caveat.
‘Manifest not found for component id’ error
So you’ve deployed your SharePoint Framework application to the app catalog and synced it to Teams. You want to add one of your web parts as a Teams tab, but instead of your web part, you see an error similar to the following:
Sorry, something went wrong
Can't load the application on this page. Use the browser Back button to retry. If the problem persists, contact the administrator of the site and give them the information in Technical Details.
TECHNICAL DETAILS
Error details: Error: ***Error initializing application. Error: Error: ***Error initializing application. Error: Error: ***Manifest not found for component id "36fdabcd-20fd-4630-a536-80495dfcfc0b".
Troubleshoot issues with Microsoft SharePoint Foundation.
Correlation ID: 2ad24b9f-c094-b000-f25f-98d6e851f7a7
Date and Time: 4/23/2020 11:53:09 PMSo what’s wrong? Wasn’t it suppose to be easy?
Deploy before use
When using a SharePoint Framework web part in Teams, the solution containing the web part must be installed in the corresponding SharePoint site. If you add the web part as a tab to a Team, the solution must be installed on the site that belongs to this Team. If you want to use the web part as a personal app, the solution must be installed in the root SharePoint site on your tenant.
When building SharePoint Framework solutions, developers can decide if they want to allow admins to deploy the solution globally to all sites or not. This is useful in cases where you’d want a particular solution to be used only in specific sites. But if you plan to use the web parts from the solution in Teams, it can get complicated pretty quickly, because if the solution is not installed in the right site, people will see error rather than your web part.
Deploying SharePoint Framework solutions is convenient but comes with a price. If you have a solution that shouldn’t be available to everyone, it might not be the right thing for you. In the end, no matter if you deploy your package globally or not, you need to ensure it’s installed in the right sites before you can use it in Teams.