C# Newsletter Management System

System Description The aim of the system is to replace the current manual based system of newsletter management with a fully automated one that can be configured by a developer once and used by any user thereafter for each layout/newsletter we wish to handle. The system must be coded in C# and no other language or platform will be accepted. The system must be built for hosting on a cloud/web farm with or without NAS. To get around the limitation of file storage the system should use cloud based file hosting. It must be built with performance in mind so it scales under load very well. There are to be no paid or licensed add-ons/controls/applications included with the system and only approved open source/free controls/applications. All source code required to compile, edit and maintain this system must be made available for review if requested and at the end of the development cycle must be handed over in full with all required resources needed for us to maintain, upgrade and improve the system. UI design is left up to the developer; but it should be made with simplicity in mind so users without any technical experience can pick it up and perform the tasks they require. Short-list of required elements • User management with varying levels of permission based access and tracking where appropriate. • Basic list management. Users will need permission to maintain local lists but not remote lists. • Layout management to allow developers to quickly edit and alter the HTML/logic. Ideally this should be handled via C# code stored in the database and compiled via CodeDom on the fly or just per change. We are open to other suggestions but they would need to offer the same level of power and flexibility without having to re-compile or alter the newsletter system itself each time. As such; technologies like XSLT are not an option, they are far too limited for the level of customisation we require. Layouts will also need to store information about where to retrieve their lists from. Either local lists or remote lists that are pulled in at the time of the send. This will allow the remote website to control access to its own database. Interfacing with websites can be via a specifically designed API (Rest/XML) or other method. Layouts must also support dynamic form creation for developers to build and sync with their logic code. This will allow each layout to have a completely custom form for resource entry by the user. Form elements must allow for the basics as well as a few more advanced types like Images (with automatic resize options), HTML Editor, colour picker etc. • UI for creating and sending. User will select a template they have access to and then be presented with the dynamically built form. There should be preview options which will build and show the newsletter with all the users entered resources build via the logic code. Users should also have a “Send to Me” option which will send the current newsletter to the currently logged in user. • Processing Layout logic should only be concerned with gathering, altering and creating data (and other advanced layout specific functions). All path information for the live URL's of the newsletter should be handled by the system instead. So all images referenced passed back to the system should be downloaded and uploaded to the cloud then the references in the passed back HTML configured. In no way should the layout logic need to know or set URL path roots. The system should support events for the layout logic that include at the very least: Dev, Test, Preview, Live. Ideally a Pre and Post of each event would be better with passed in status information about the send e.g error state. This is so the logic code can know when to tell the parent website there is a new live newsletter to add to its archive list for public users to view and pass it the URL. All required resources for a newsletter to display correctly should be uploaded for each newsletter send so that when th