1. Stay tuned
    2. Blog
    3. 2016
    • Published
    • 4 min

    Configuring the Add-On Store in Episerver 7, 8 and 9

    To be able to access, browse and control how add-ons are installed via the Add-On Store, there are some config settings you need to be familiar with.

    By Arild Henrichsen
     
    I know, there are mixed feelings about the Add-On Store, but that's a topic for another blog post. This is for those of you how DO decide to make it available on your site.
     
    Take a minute to consider WHO should have access, and WHAT they should have access to. General rule-of-thumb: Restrictive is better, and keeping your codebase in sync with what's actually on the live site is crucial for the stability of your site.
     

    Enabling the Add-On Store menu item

    For users to even be able to access the Add-On Store, they must be a member of the PackagingAdmins group, which actually is a built-in virtual role. 
    (Note: Virtual roles don't show up in the Administer Groups admin tool, and you don't have to create them manually in the admin UI.)
     
    PackagingAdmins is not assigned to anyone by default, so go ahead and add it manually to the <episerver.framework> section of your web.config (or episerver.framework.config, if your config is split into separate files): 
    <episerver.framework>
     <virtualroles>
         <add name="PackagingAdmins" type="EPiServer.Security.MappedRole, EPiServer.Framework" roles="WebAdmins, Administrators" mode="Any" />
     </virtualRoles>
</episerver.framework>
    In this example, any users belonging to either WebAdmins or Administrators will also become members of the PackagingAdmins virtual role. This will make the Add-Ons menu item visible in the global menu.

     


    Installing Add-Ons from code or via UI

    In Episerver 7, add-ons could only be installed via the UI, either directly from the one-click-install listing, or by manual uploading a nuget package. Once a user was given access to the Add-On Store in Episerver 7 (being PackagingAdmins), they had access to both browse and install available add-ons. 
     
    In Episerver 8 and 9, there is a config setting to specify if add-ons should be installed from code or via the UI. The new installationMode attribute can be found in the <episerver.packaging> section of your config file. 

      
    <episerver.packaging installationMode="UI" />
    • The user is allowed to browse and install add-ons (including manual upload). 
    • The Add-On Store will still probe the site for add-ons installed from code (via Visual Studio). These will show up in the Installed section of the Store, but it's not guaranteed that operations like disable or uninstall will work.

    <episerver.packaging installationMode="Code" />
    • All add-ons must be installed as nuget packages in Visual Studio, and then be deployed with the rest of the site.
    • The main advantage of this mode is ensuring that the code repository contains all Add-Ons in use on the site (and thus testable before deployment to a live environment).
    • In some environments, such as load-balanced servers or Microsoft Azure, deploying Add-Ons from code is the only option that works.
    • In this mode, the user will be notified that he's only allowed to browse. 

    Episerver Add-On Store browse only

     

    Default Episerver Add-On repositories

    There are 3 built-in add-on repositories:
    • EPiServerAddOns - official and supported add-ons by Episerver
    • EPiServerBetaAddOns - add-ons under development, provided unsupported and as-is
    • ThirdPartyAddOns - add-ons provided and supported by a third party developer 
    These are enabled by default, with no configuration necessary (they are initialized automatically by the Episerver.Packaging assembly). 
     
    You might want to disable some (or all) of these, for instance if you don't want a user to mess around with the beta add-ons. Do so in the <packagingRepositories> section in your config file: 
    <episerver.packaging>
     <packageRepositories>
          <clear /> <!-- will remove ALL repositories -->
          <remove name="EPiServerBetaAddOns" /> <!-- will remove a specific repository -->
     </packageRepositories>
</episerver.packaging>

     
    Episerver default Add-On Store feeds




    Custom Add-On repositories

    If you want to add your own custom feed, add it to the <packagingRepositories> section in your config file: 
    <episerver.packaging>
     <packageRepositories>
          <add name="MyCustomFeed" url="https://nuget.mydomain.com/feed/myaddons.svc" />
     </packageRepositories>
</episerver.packaging>


    You could even filter the feed on specific tags, to avoid showing the whole feed, using the     filterTag attribute:

    <episerver.packaging>
     <packageRepositories>
          <add name="MyCustomFeed" url="https://nuget.mydomain.com/feed/myaddons.svc" filterTag="myTag"/>
     </packageRepositories>
</episerver.packaging>

    The results would be similar to a filtered search in the official Episerver nuget feed. 
    (Episerver's 3 main filterTags for their official feed are "EPiServerAddOn", "EPiServerBetaAddon" and "ThirdPartyAddOn".)
     
    Custom Add-On Store feed

     


    Troubleshooting: "No add-ons are available"

    No add-ons available error
     
    Quick checklist: 
    1. Your user is in the PackagingAdmins group
    2. installationMode attribute is set to "UI" in the <episerver.packaging> section
    3. You haven't disabled the default Episerver add-on repositories in the <packageRepositories> section
    4. Your server is able to ping the official Episerver nuget feed at http://nuget.episerver.com/feed/packages.svc/
    I DotPeek'ed the Episerver.Packaging.Configuration.EPiServerPackagingSection namespace in the Episerver.Packaging assembly, and found the following:
     
    The default repositories are initialized using the URL https://nugetaddons.episerver.com/feed/Addons.svc. 
    It seems to be a valid URL (although I'm not sure why they're not using the official nuget URL http://nuget.episerver.com/feed/packages.svc/). 
     
    Anyway, the simple solution seems to be that the Episerver license for the nugetaddons.episerver.com site needs renewing (causing the feed XML to be invalid)...
     
    Nuget feed license missing
     
    This config applies to Episerver.Packaging 3.2.2.0 (shipped with Episerver 8.x) and 3.2.3.0 (shipped with Episerver 9.x)
     
    (Episerver 7 is not affected - Episerver.Packaging 3.0.1845.0 shipped with Episerver 7.x uses the nuget URL https://addons-api.episerver.com/feed/ , which is surely outdated, but works.)
     
    Temporary solution: Remove the default feed, and re-add it using the official nuget URL and a filterTag:
    <packageRepositories>
      <remove name="EPiServerAddOns" />
      <add name="EPiServerAddOns" url="http://nuget.episerver.com/feed/packages.svc/" filterTag="EPiServerAddOn"/>
     </packageRepositories>
     
    My tip for Episerver: Consolidate your nuget feeds!
     
    Update: Episerver have confirmed it's intentional to have separate nuget feeds for the Add-On Store UI and Visual Studio, which is why Episerver.Packaging is initializing from https://nugetaddons.episerver.com/feed/Addons.svc.
     
    Quote:
    "Addon packages are available from both nugetaddons.episerver.com and nuget.episerver.com, new packages are published to both feeds in parallel. The UI in CMS still uses nugetaddons.episerver.com. In Visual Studio you should use nuget.episerver.com for all your episerver package needs."