OT: Separation of Concerns-related Design Decision

I'm writing a utility app that installs stuff (copies files to folders,
installs assemblies to the GAC, executes scripts gainst a SQL Server
database, etc).
As part of the design of this utility, I'm breaking out specialized
"installers" into their own assemblies (.dll). So one "installer assembly"
will take care of GAC installations, while another executes scripts against
the SQL Server. The hosting application will enable the user to specify
various installation options that are passed to the "installers" at runtime.

Of course I want for a log (simple text file) to be updated for each
installatoin operation, with associated success/failure outcome, date time,
etc data.

The question here has to do with "where to implement the logging feature?" I
see two reasonable options.

1. Each "installer assembly" can take care of its own logging.

2. The "installer assemblies", instead [of logging], raise events containing
the data that would otherwise get logged. The hosting application would then
respond to the events and write the data to the log fil, optionally ignore
the event data, or display the event data to the user (in addition to
logging), etc.

What would you consider to be the better alternative - and why?

Thanks!


.

Relevant Pages

  • Re: Replace MSDE with SQL2000
    ... Above implies that you have both the MSDE that came with BE installed as ... Note that service pack installs are different between MSDE and the regular ... SQL Server, as they use different setup engines. ... Moving SQL Server Databases ...
    (microsoft.public.sqlserver.setup)
  • Re: Re-adding noded to cluster
    ... It is easy to evict a cluster node, repair or rebuild, and, perhaps even ... Run SQL Server setup to manage the virtual server configuration and add ... This installs the RTM binaries to the ... Reboot the added node. ...
    (microsoft.public.sqlserver.clustering)
  • Re: SQL 2000 and MSDE/Express/Compact edition..
    ... I know you can do silent installs to remote clients of SQL Server 2000, but I am not sure about MSDE. ...
    (microsoft.public.sqlserver.replication)
  • Re: Is it MSDE or SQLServer
    ... You can try to check if the SQL Server tools are installed. ... but I don't think anyone installs a server without installing the ... and MSDE doesn't come with the tools. ... > (without connecting to the database) because for all intents and purposes, ...
    (microsoft.public.sqlserver.msde)
  • Re: SOLUTION: Patch availability for the .NET Frameworks SDK installed MSDE
    ... but this probably needs to be directed to a place that SQL Server folks frequent. ... installs with no problems. ... another problem associated with this patch seems to have cropped up: ... > error message text received, ...
    (microsoft.public.sqlserver.security)