November Happy Hour will be moved to Thursday December 5th.
AI OnAI Off
Packaging of custom module
Regarding the shell module vs addon part:
Module.config is a per-module file located in the base directory of each module so having config transforms should not be necessary if this thing itself is an actual module (it would have its own file). http://world.episerver.com/Documentation/Items/Developers-Guide/EPiServer-Framework/7/Configuration/Configuring-moduleconfig/
Even if you do not make an add-on you should still be able to register it as a shell module (like for instance some of the EPiServer products have been registered since CMS6). Note that if you you can specify the path where it can be found as well as assemblies for the module if you register it in web.config. http://world.episerver.com/Documentation/Items/Developers-Guide/EPiServer-Framework/7/Configuration/Configuring-episervershell-Section/#protectedModules
An add-on essentially is a shell module that is packaged in a special way which allows the system to deal with dependencies, deployment (and configless discovery), upgrades, etc.
Regarding the reference problem it really means that neither option is great (either your non-addon will reference an add-on assembly that may change or if packaged as an add-on the code referencing yours will be in essentially the same situation). As you suggested it seems to fall in the category of "interfaces that should be moved to actual platform assemblies".
Mar 25, 2013 10:21
Joel, is there any point of installing and using your module as standalone add-on?
Is it standalone module or it is mostly library that should be used by other add-ons? Or both?
Mar 25, 2013 14:15
Thanks Håkan!
Dmytro, I guess it's a bit of both. It's primarily a UI component but it needs definitions in code to function meaning that it needs to be referenced either by the site or a component that knows both about the module and the site (page types etc).
Anyway, using the shell module approach works with the exception of having to reference Cms.Shell.UI but I know you guys know about that problem already.
Mar 25, 2013 18:54
This thread is locked and should be used for reference only. Please use the Episerver CMS 7 and earlier versions forum to open new discussions.
I have developed a "module" that I'm planning on open sourcing. It is comprised of both C# code and JavaScript and defines a component (has class inheriting ComponentDefinitionBase). It requires configuring in a module.config. The module has a dependency on EPiServer.Cms.Shell.UI.
In order to use the module small piece(s) of code will need to be created on the site using it. In order to write this code both the module's assembly and EPiServer.Cms.Shell.UI needs to be referenced.
Putting the problem with referencing EPiServer.Cms.Shell.UI in a project aside - I'm going to ignore it until some interfaces is moved out of it - I would really appreciate some pointers on how to distribute it. NuGet is attractive as the assembly needs to be referenced, but I guess I will then have to create config transforms or PowerShell script for module.config. Packaging it as an add-on solves that but that doesn't feel natural as the assembly should be referenced on the site.
Any thoughts from the packaging gurus at EPi? As I mentioned before, for now let's ignore the issue with referencing Shell.UI :)