AI OnAI Off
Base library for common integrations and Epi specific configurations
Hi,
I think you should separate the integrations to a separate solution without any Episerver dependencies and distribute these as NuGet packages to the projects that need the integrations (this is what you would do in any software project, reusability).
Then you could create additional NuGet packages (Episerver specific integration NuGets) that can have dependencies to Episerver as these would be used by the Episerver projects (and these packages naturally would consume the integration NuGet packages).
Have your Episerver specific helpers in their own NuGet packages. Take the lowest major Episerver version dependency in the NuGet packages (this same applies to your Episerver specific integration NuGet packages, assuming your Episerver projects could be running different versions of Episerver).
Setup a NuGet feed for these packages so that the different projects can easily get access to these packages. Your feed could be hosted in Azure DevOps, own NuGet server, MyGet service (private feed), or somewhere else (it could even be a network share in your corporate network).
Cheers, Antti
Dec 01, 2018 9:35
I'm currently helping a client who has multiple Episerver projects. The projects are somewhat similar as they all operate within in same market, and they all require integrations to some of the same external systems.
Now they would like explore the possibility of having a shared library across all their Episerver projects. Either as a submodule or perhabs a Nuget package.
Does any of you have experience with a setup like that for Epi projects? If so, what sort of stuff do you normally place within the assembly? And what about Epi specific stuff like custom helpers, attributes and initialization modules?
Appreciate any inputs as I am currently struggling to decide if it is even worth the effort, when considering the required maintenance and the fact that the projects will eventually differ in some way.
Thanks