In our project we have our content types in a different project than the web project. We are able to install the new EPiServer.Forms package in the web project, but when trying to add the package to the other project, we get the following error "Protected modules path can't be found. Check the WebConfig or related connected config file to see if protected modules location is given".
We need the reference in order to restrict a ContentArea to only allow types of FormContainerBlock.
I noticed a similar issue previously when installing on different implementations (the web project). Adding the following line in the <virtualPathProviders> section of <episerver.framework> of my .config file resolved the issue for me:
<add name="ProtectedAddons" virtualPath="~/EPiServer/" physicalPath="Modules\_Protected" type="EPiServer.Web.Hosting.VirtualPathNonUnifiedProvider, EPiServer.Framework" />
So you may need to add the <episerver.framework> section to your app.config in the other project as I am guessing the installer looks for that particular entry in the config when installing.
Let me know how you get on?
I tried your fix, but I still got the same error. However, it worked when I renamed my app.config to web.config. Didn't even need the config changes you mention. I assume EPiServer only looks for the web.config, forgetting to fallback to app.config.
PS: Installing the EPiServer.Forms package takes several minutes, because it downloads and insert a bunch of client resources to its modules folder. Would it be a good idea to change the EPiServer add-on installation process so that it only downloads and places these client resources if the package is being installed in a web project? ...Or maybe a better idea would be to separate the EPiServer.Forms package into EPiServer.Forms.Core and EPiServer.Forms.UI (which depends on Core), so that our Core project only depends on the EPiServer.Forms.Core package?
I had the same problem and it was fixed renaming app.config to web.config. I find it very strange that Episerver hasn't used the same principal for Episerver.Forms as they use for other components by dividing it into Episerver.Forms.Core and Episerver.Forms.UI (also mentioned by Lars here).
We filed a story for this AFORM-571
But honestly, this will need PO decision to split. Though not technical-complicated (we are investigating), my DevTeam cannot make it solely on our own.