Is it possible to develop in No-Code Sandbox Solution style with Sharepoint PnP?

Copper Contributor

Hi there,


Hopefully someone will be able to address my confusion regarding SharePoint PnP and sandboxed solutions. My understanding so far:


  • PnP can deploy practically all the same artifacts one can provision via a .wsp file
  • PnP can provision .wsp files directly but at a cost of a chance to ruin the composed looks gallery
  • PnP is more flexible than .wsp - for example it is capable of incremental provisioning
  • There is no generally available Visual Studio support for PnP based solutions, at least those not based on SPFx.

Questions / statements to be validated or disproved:


  • As far as I understand, there's no automated way to convert a traditional sandboxed solution Visual Studio project into a PnP schema (nor the opposite is possible)
  • There are no production-ready Visual Studio extensions that would allow working with a PnP schema like with a full-fledged SharePoint project
  • Even with Visual Studio code, there is only limited support for SPFx-based solutions

Given the above, what would be the sweet spot for the PnP? Is it only good for SPFx and turning a bunch of SharePoint Designer customizations into a single deployable unit so far? And if I for example need to provision list workflows then I am stuck with the good old .wsp plus perhaps good old PowerShell scripts for provisioning things like quick launch navigation?

Would appreciate any advice / feedback on this. Thanks!

5 Replies

Hi, @Dmytro Lapshyn


You are confusing things a bit. I personally like to think that PnP provides solutions to all the problems in SharePoint development (and more than that).

You can start here:

Also, the GitHub repository is a never-ending list of extremely useful solutions and samples (for both classic and modern experience). Definitively have a look here:   


In this case, I assume you are referring to provisioning, so in short, I would suggest that you stop investing your time in WSP solutions and start using PnP as soon as possible.

There is a PnP provisioning schema  (check the latest version by date) file that you can use in your code editor to get validation. 


In short, PnP  will probably have a solution for all of your problems! You just need to look for it, but it probably exists! If it doesn't, raise the discussion and someone will offer you some options ;)


Hope this helps you get started and potentially join the community later on :)





Hi Joel!

Thanks a lot for the prompt reply!


In this case, I assume you are referring to provisioning, so in short, I would suggest that you stop investing your time in WSP solutions and start using PnP as soon as possible.


I would be happy to, but wouldn't that mean that I would loose access to all the Visual Studio tooling for making content types, list definitions, workflows etc.? This is actually my biggest concern so far, as going backwards to a plain text editor sounds scary especially given the amount of cross-dependencies and the complexity of CAML (not even mentioning workflows which I've always designed only visually).


I understand there's an XSD schema for the provisioning file itself that I can use for validation, but it won't help me much with all the CAML, elements.xml etc.

It may not sound like that at the start and when you are comfortable with the tools you currently use, but once you get into it, you will be a lot more productive. Also look at the PnP PowerShell for provisioning scenarios as sometimes it's a lot simpler than a full C# application.
The PnP provisioning engine is just amazing! The option to save a site as a XML template is pure gold ;)
And you can use any code editor of your choice, including Visual Studio.
The documentation is very good, and you have lots and lots of videos on the PnP channel with tutorials.
The SharePoint development sorry was never so strong :grinning_face:
Chalk another one up who loves using PnP!

You can do more with less in PnP, we’ve a number of site provisioning scripts written purely using PnP, some even writing to SP lists which is then firing off a Flow notification. It’s incredibly flexible and powerful.

We’ve ditched our WSP model mainly because it simply doesn’t scale in a large organisation. Makes adding new SP artefacts more difficult. For example, adding new views to all document libraries is a couple lines of PnP and CAML.

Similarly, if the CTH isn’t being used to deploy content types, then PnP can do a similar role.

Hi @Joel Rodrigues and @Steve Johnson ,


In retrospective, you both are totally right. We are using PnP for our current internal SharePoint project, and I have also started using PnP for applying updates to an originally SharePoint Designer-authored web, which turned out to work quite good.


As for workflows, we've found a way to design them in Visual Studio and then compile into a form that could be provisioned via PnP.


Thanks a lot for the inspiration!