Feature: Persistent Logs

[hecon5]

One thing I'd like to implement is persistent logging in this application. The current add-in gets obliterated when it's unloaded, so any logs need to stay external to the addin, either via a log file or a separate "backend" addin database. These both have merits and detractors, so I thought it best to discuss.

Why implement:

• help track down intermittent bugs
• timing checks between development
• complete deploy logs when using a runner for build.
• per-application build notes

Before I got too far, I thought I'd make an issue for discussion.

I've also built up on the clsLog pretty significantly, and almost have this ready as a drop-in replacement for the current clsLog, which can also capture user inputs and messages sent to the user during build.

[josef-poetzl]

If I understand you correctly, you are primarily concerned with build logs.
(The export informations could be included directly in the repository).

For example, I use the "Run Before Export" feature to start a procedure in an add-in.

Just as an idea:
Would this "Build Logger" perhaps also be an addition (add-in) that could be started via "Run After Build" and, for example, collect the result of Log and process it further?
Or perhaps you could also design an interface that you can activate in "Run Before Build" and "hook into" (e.g. via call back procedures) the logger.

Something to consider:
Maybe allow more than just one procedure to be started?

My main thought here is that VCS should be VCS and not take on additional tasks. It is better to create an interface that allows these "non-VCS" tasks to be performed with other add-ins.

[hecon5]

primarily concerned with build logs.

Not really; logs at large are the concern. This affects all parts of using the addin, export/import/build/add in development, etc.

Would this "Build Logger" perhaps also be an addition (add-in) that could be started via "Run After Build" and, for example, collect the result of Log and process it further?

No, this would be an integral component of the addin; it would be only concerned with logs from the addin itself (build/export/settings management/errors from the add in).

My main thought here is that VCS should be VCS and not take on additional tasks. It is better to create an interface that allows these "non-VCS" tasks to be performed with other add-ins.

This would only be concerned with MSAccessVCS Addin, nothing external. This would be a log function which replaces the existing clsLog function.

The only reason I mentioned 'external' to the addin was that the ephemeral nature of addins: they are effectively 'reset' to their prior state as soon as Access unloads them (either by closing Access or otherwise being unloaded). This would not be expected to load / save logs from anything else...though one could conceivably build that into a collector...that would be entirely out of the scope of this effort.