bi01081993 / ncron

Automatically exported from code.google.com/p/ncron
Apache License 2.0
0 stars 0 forks source link

Restructure projects and deployment strategy to avoid DLL hell #13

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Currently, deployment of NCron (1.0 and 2.0/trunk) goes something like 
this:

On development machine
 * Create new library project, referencing NCron.Framework.dll.
 * Add classes implementing ICronJob to library, and compile library.

On server
 * Install NCron using MSI, InstallUtil or command line option.
 * Add job library manually to NCron installation folder.
 * Configure NCron to execute jobs according to schedule.

When jobs are changed/added to the job library, the DLL is recompiled and 
copied to the server again. This is fine as long as the version of the 
NCron.Framework.dll in the development environment matches that installed 
on the server. Updating to a newer version of the framework, requires a 
new service EXE to be installed on the server as well.

Things get even worse when integration projects, such as 
NCron.Integration.Autofac, is added to the mix. This assembly typically 
installed only on the server, and its reference to Autofac.dll might not 
match the version referenced by the job library. Similarly if the job 
library references something like NHibernate, which has a dependency on 
some specific version of log4net, the versions required by 
NCron.Integration.log4net and NHibernate might not match.

To solve this DLL hell, the entire deployment process could be 
restructured into something like this:

On development machine
 * Create new CONSOLE APPLICATION project
 * Referencing NCron.Framework.dll and NCron.Service.dll (possibly 
combined)
 * Add an application entry point that calls the NCron.Service.Program.Main
(args)
 * (Before that call, the service could be configured programmatically.)
 * Add classes implementing ICronJob to project, and compile application.

On server
 * Add compiled service assembly from development.
 * Install as service InstallUtil or command line option.

Integration projects should be provided as source code, which can be added 
to users projects. The user now has complete control over every single 
dependency, and an update cron service can be deployed (almost) as simple 
as xcopy (script for stopping, uninstalling, copying, installing, 
starting) can be included in distribution of NCron.

Original issue reported on code.google.com by jsr%mala...@gtempaccount.com on 21 Jan 2010 at 4:11

GoogleCodeExporter commented 8 years ago
Trunk is unstable from revision #82 until this issue is resolved.

Original comment by jsr%mala...@gtempaccount.com on 21 Jan 2010 at 4:24

GoogleCodeExporter commented 8 years ago

Original comment by jsr%mala...@gtempaccount.com on 25 Jan 2010 at 9:22