I'm trying to develop two add ons, one being an add on with common features that other add ons will have as a dependency and an example add on that depends on this but I'm currently running into the following error.
As far as I can tell I've setup the nuspec files properly with the Example setting the Common module as a dependency. The issue seems to relate to the dlls in the modulesbin folder and some validation done on startup. The following is the stack trace from the error.
EPiServer.Shell.Modules.ModuleTable.CheckAssembliesAlreadyRegistered(ShellModule module) +394
EPiServer.Shell.Modules.ModuleTable.Add(ShellModule newModule) +127
EPiServer.Shell.Modules.ModuleTable.AddRange(IEnumerable`1 modules) +68
EPiServer.Shell.ShellInitialization.Initialize(InitializationEngine context) +114
EPiServer.Framework.Initialization.ModuleNode.Execute(Action a, String key) +43
EPiServer.Framework.Initialization.ModuleNode.Initialize(InitializationEngine context) +80
EPiServer.Framework.Initialization.InitializationEngine.Initialize(HostType hostType) +118
EPiServer.Framework.Initialization.InitializationModule.Initialize(HostType hostType) +337
EPiServer.Framework.Initialization.InitializationModule.FrameworkInitialization(HostType hostType) +83
Or After reading this post again would it be better to create a standard .Net Dll containing the common/core functionality and reference that in both the main EPiserver project and the Addon.
It looks like you have your Common assembly included in both Add-Ons, which might cause this exception.
If you need to reference Common assembly from the main project, then it is better to not create an Add-On from it and just place the assembly on your site. Consider a scenario when user deletes the Common Add-On. If you want to be able to distribute it - create a standard NuGet package from it (the one that can be installed from Visual Studio). In the example Add-On you can specify the Common assembly as a prerequisite, see more about it here and here.
The common assembly is one of the Add-Ons so it will obviously include itself(but has no dependencies). The scenario we have is that we are looking at having a common add on containing common functionality that all our other add-ons will have a dependency on. The above error occurred when I tried to see how this would work in a prototype with two add-ons. I was assuming that because the second add-on (Example) declared a depenency on the first add-on (Common) that it wouldn't try and load the common dll again but this is exactly what it seems to be trying to do.
I have read the linked pages but it seems that I am still missing something in how to setup nuget and dependencies correctly. As far as I can tell I have setup the nuspec files properly with the Example add-on declaring a dependency on the Common add-on. Also this is a purely MVC 4 EPiserver 7 Project and Add-ons.
Ok. According to scenario that you described the Common assembly should be a part of the Common add-on, but it should not be a part of Example add-on. Example add-on should only have a dependency declared in the nuspec file that points to the Common add-on.
The error message that you have got indicates that the Common assembly is registered in more than one module (add-on). An assembly can be registered within a module in several ways – it can be placed in the bin subfolder of the module folder, it can be specified in the module.config or it can be specified in the web.config.
On a site were you have your add-ons installed, could you check the Modules\Example\bin folder – you should have only Example assembly there, but not Common assembly. The “Modules” folder that you need to take a look at can be the one that is under the site root or in VPP folder, depending on weather your add-ons are public or protected.
Do you have Modules\Example\module.config file? If so, which assemblies do you have listed in it? Common assembly should not be listed there.
Check if you have your Example or Common modules registered explicitly in the sites web.config - in episerver.shell/publicModules or in episerver.shell/protectedModules. They should not be registered there if you plan to deploy those modules as add-ons.
Thanks, yeah the issue was the modules/example/bin folder. This was while developing the add on so I have decided to move the visual studio projects for add-ons out of the modules folder so that this doesn't become an issue during development.
Then similar to this guide I have added msbuild targets to the project file to copy the required files to the modules directory when the add-on solution is built.
I'm not sure why some of the guides recommend having the add-on projects nested in the modules directory in the main EPiServer project but it makes it untidy and likely to cause issues like this.
Thank you for the feedback. There is a note in the guide that might be helpful in your case:
Note regarding library references: if you are going to add a reference to one of the EPiServer libraries or a library that is a part of some other add-on to your project, please make sure you set "Copy Local" to False, so the referenced library will not be copied to the add-on project output folder
The main advantage for having add-on projects inside your site project is that any changes in add-ons templates or client files can be seen immediately on your development site without copying files. Changes in add-ons server side code requires only compilation in order to see it on the development site.