Khurram
Mar 14, 2014
  8297
(3 votes)

EPiServer 7.6 Protected Site Add-Ons location.

Before EPiServer 7.6, the public Site Add-Ons have been placed at /modules/ under the site root and protected Add-Ons placed at ~/protectedModulesPath/Modules or appDataPath\Modules location. But with the release of 7.6, We’ve started streamlining the disk location for Site Add-Ons which means all the Site Add-Ons will be placed under the same root location (/modules/) regardless of the type of the Add-On.

We are making this decision because of a couple of reasons;
the first reason is that CMS, Shell and Add-On Store UI have been converted to NuGet packages so when Installing these packages from NuGet we need a place to put all the resources (aspx files, javascript resources, images etc.) to some path which we can find later (to upgrade these packages) without any surprises.
The second reason is that we want to recommend a standard location inside a deployed EPiServer site where all the third-party Add-On developers can happily put their resources and upgrade them later through NuGet or EPiServer Add-On store and it makes it simpler to reason about the location of every Add-On installed through Add-On store or NuGet specially when you’ve installed a lot of them. 

If you’ve already installed/upgraded to EPiServer 7.6 you’ll notice that the installation process has created a new folder /modules/_protected inside the site root. This is the new home for EPiServer protected Site Add-Ons. From now on, all the EPiServer developed protected modules will be placed under modules/_protected.

If you are upgrading from an older installation to release 7.6, the process will clean the folders CMS, Shell and CMS.Sources from old protected modules location (relevant dll files will also be deleted from /modulesbin/). And two new folders (CMS and Shell) will be created under /modules/_protected/ location. 

In the same way if you upgrade to EPiServer Add-On Store UI 3.1 (via Nuget), the installation will delete EPiServer.Packaging and EPiServer.Packaging.UI folders from current modules path and EPiServer.Packaging.UI folder will be created under /modules/_protected location.

EPiServer Add-On Store UI 3.1 package also introduces a new command let within the Visual Studio Package Manager Console. This command let will help you in moving all the current protected Add-Ons to new location. 
In order to run this command let, first you need to upgrade to new Add-On Store UI package through NuGet (Install-Package EPiServer.Packaging.UI). Once the process of installation completes, You can run Move-EPiServerProtectedModules in Package Manager Console (Tools --> Package Manager –> Package Manager Console) and it’ll move all the current protected modules to new location, it’ll also write the information in web.config and will delete the old folders.

Mar 14, 2014

Comments

Johan Book
Johan Book Oct 16, 2014 10:32 PM

Great article! So does this mean that modulesbin is now obsolete? I tried to remove modulesbin (which was empty) together with the probing element in web.config but got a YSOD saying "Probing path 'modulesbin' should be specified in web.config"... Should we point probing to modules instead?

192.168.l.254 192.168.1.254
192.168.l.254 192.168.1.254 Sep 7, 2018 05:27 PM

192.168.1.254

Please login to comment.
Latest blogs
Telemetry correlation for Scheduled Jobs in Optimizely

I previously demonstrated how to correlate telemetry to Azure Application Insights within a Hangfire job. But how about those jobs that are built a...

Stefan Holm Olsen | Mar 23, 2023 | Syndicated blog

Fixing Optimizely Content Syncing/Caching Issues on the DXP pre CMS.Core 12.13.0

Hi all, With our recent deployments to the DXP for .NET 6 projects (one a new build and one an upgrade) our clients had raised issues where there...

Scott Reed | Mar 23, 2023

Handle hostnames, schedule jobs and role access when synchronizing content

The Environment Synchronizer module helps you to set your environment into a known state after synchronizing databases between environments. In thi...

Ove Lartelius | Mar 23, 2023 | Syndicated blog

4 tips and tricks for Hangfire on Optimizely CMS

Here are four useful tricks I always apply to any site where I use Hangfire (code included).

Stefan Holm Olsen | Mar 21, 2023 | Syndicated blog

The new LinkItem property in Optimizely CMS, and why it matters

In the past, we have used different tricks to achieve this. Now, the LinkItem property is finally built-in in Optimizely CMS 12!

Tomas Hensrud Gulla | Mar 20, 2023 | Syndicated blog

A day in the life of an Optimizely Developer - Vertical Slicing in CMS12

There is such a vast choice these days in how you can build a website, aside from all of the different programming languages out there, there are...

Graham Carr | Mar 20, 2023