This release contained a refactor of the system startup and shutdown logic as well as T4 templates for code generation to create 99% of the files needed for a new module.
We needed a way to expose ELEFLEX web and WCF classes but without having to install all the web user inerface components as is currently required with the Eleflex.WebClient package. A new package Eleflex.Web was created to house the core ELEFLEX web and WCF components, leaving the web user intrface components with Eleflex.WebClient.
The current email service in ELEFLEX simply send an email to current SMTP server defined and if an error happened, the email was lost. The Eleflex.Email module creates a new service that first store emails, then using a background process, send emails and later purge them to clean up history.
You can now generate 99% of the files needed for a module after you create a new Entity Data Model and modify the template parameters to your solution specifics. After changing the values for namespace name, module name, location of EDM, and others, running the template will create all the models, storage repositories, business repositories, service repositories, dispatchers, interfaces, object location configs, automapper configs and more! We are working on a NuGet package that will generate a complete solution for you to build your next module, coming soon!
We found issues with the initial version of the system startup and shutdown process because not all assemblies were being loaded into the application domain with .NET 4.6 and IIS. This became aparent with the application pool recycled and background processes were trying to "spin up" a new background process instance. Not only did this affect assemblies being loaded into the app domain, it also interfered with static variables being set and having to use older reflection methods due to name conflicts with dynamic dirs.
System startup was refactored so that the process tries to load all assemblies in the app domain first before executing logic. First the process would dynamically creating instances of startup tasks with registration, then locating and creating instances of registration tasks linked to the startup tasks using a custom attribute. After the process has completed this for all startup tasks, the process would then reload all asseblies from the app domain and do the first step once more, allowing leaf assemblies in the reference tree to finally be included in the app domain. Lastly it would then go and execute startup tasks in order after they have all now been discovered.