>
>
> - Ants
>
> On Sun, Aug 7, 2022, at 07:21, Dominik Psenner wrote:
>
> You're very welcome.
>
> At some point it will be necessary to define how to implement the usecase.
> If you need even more flexibility and extendability, maybe even at runtime,
> it may
On Sun, Aug 7, 2022, at 07:21, Dominik Psenner wrote:
> You're very welcome.
>
> At some point it will be necessary to define how to implement the usecase. If
> you need even more flexibility and extendability, maybe even at runtime, it
> may be wise to not implement a single ap
You're very welcome.
At some point it will be necessary to define how to implement the usecase.
If you need even more flexibility and extendability, maybe even at runtime,
it may be wise to not implement a single application with plugins but
rather leverage flexibility through se
Thanks. I will look into this. However, I have no control over the parent
process that loads plugins (for example my plugins), ruling out alternative 1.
Again thanks!
Med vänlig hälsning
Fredrik Pålsson
Projektledare
ISG Nordic AB
+46 733-46 21 48
•
+46 42-36 21 48
fredrik.pals
James,
I originally thought the same about log4net plugins.. But it turned out
that they seem to be a method for injecting messages into the logging system
that came from somewhere else.
In your case, you've defined a new appender that happens to be in a separate
assembly. The good ne
he plugin architecture of log4net. I'm imagining my main application using
the vanilla 1.2.10 log4net assembly plus an assembly containing my plugin.
I've found there to be little to go on really though regarding the intended
use of plugins and examples - this being the only thread in th
