As SharePoint Framework solutions are deployed as tenant-wide app packages, the client app package needs to deploy in the tenant app catalog. And all these instances of the web parts refer to the bundled JavaScript files from the CDN location specified in the package that is deployed in the app catalog. So, by following the software development lifecycle, it needs to have the ability to run development, staging and production environments as different site collections in the same tenant.
And then this becomes a problem for us, as these development, staging or production versions can be different based on the development timeline. But the app always gets the web-part files from only one CDN location. So, here we need multiple app packages deployed in the app catalog. But whenever we try to deploy the app package to the catalog, it is updating only the instances previously deployed. Even if we try to change the name, it will not work.
So, after going through some procedures, I have found a solid solution with minimal effort. The details and methodology are described below,
Change in package-solution.json file
First Change the “name” attribute under the solution. Also, we need to replace the “id” with a newly generated GUID. To generate a new GUID, we can use visual studio GUID generator or any other online GUID generators. The GUID generation procedure is described in detail in this article under “Generate New GUID” section. Also, we need to change the package name under “Paths”.
![SharePoint]()
Fig: Package-solution File
Generate New GUID
![SharePoint]()
Fig: Open GUID Generator in Visual Studio
To create a new GUID, we need to open Visual Studio. Now, go to the Create GUID option under Tools Tab. A new popup window will open. An important note about putting upi a new GUID is to make sure the newly-generated GUID is in lowercase. Visual Studio GUID generator provides GUID with upper case letters. We have to convert it into lowercase otherwise it gives a compilation error.
![SharePoint]()
Fig: Generating New GUID
Now select the the fourth option of GUID format, as we need the GUID in Registry Format as shown in the figure’s first position. Now Press the new GUID button as shown in the second position of the figure. A new GUID will generate as shown in the third position.
Change in package.json file
Now we need to change the "name" attribute in the package.json file. I have changed the name from “wire-transfer” to “wire-transfer-stg”.
![]()
Fig: Package.json file
Change in .yo-rc.json file
We need to change the value of “libraryName” and “libraryId” attribute. One thing you need to remember is that for the “libraryId” attribute value, you need to provide the same GUID as provided in the in package-solution.json file.
Change in <WebPartName>WebPartName.manifest.json file
Now we need to change the web part’s manifest file. Web part id has been stored here. We need to change this web-part id. Here, you will find two attributes as ID and GoupId. But you must provide the same GUID. One thing to remember here is, we have to do this procedure for all the web parts we're using in the project.
![]()
Fig: Web part manifest file
Deploy the web part files and package
After completing the procedure as described above, we need to build the package and web-part files. Then we need to deploy the web parts. Check out this article “Deploy SharePoint Framework Client-Side Web Part To Office 365 CDN”. Here you can find the detailed procedure of deployment of the SPFx Client-side web-part. Then we can add the client app on the site, and we will find both instances working fine as they are deployed.
Conclusion
By following the above procedure, we will be able to deploy both instances of the same app. And we can add them to our targeted site as we need. I have documented the procedure as I have not found the full procedure online. And if you have found some better procedure please let me know to update the documentation.