Nlog: New syntax for registering ConditionMethods via code?

[TheXenocide]

NLog Version: 4.4.1
Platform: .NET 4.5

Not really sure if this would be considered a bug or a feature or just a question, but it looks to me like there's no suitable manual registration method for ConditionMethods that matches the new syntax style found in the examples for other extensions here. I'm trying to prototype some stuff in LINQPad where configuring NLog using code for now and I'm finding it would be nice to be able to point NLog at my static class decorated with ConditionMethods, rather than use the extensions configuration element (probably using the typeof format, since static classes can't be used as Generic Type Arguments). It looks like in the meantime, I can probably use the older style like the following example (haven't tested this yet, but it looks like it will probably work), but I thought I'd point out the discrepancy since it looks like there's some movement to provide a different mechanism for registering extensions with code.

```c-sharp
ConfigurationItemFactory.Default.ConditionMethods.RegisterDefinition("has-diag-category", typeof(NLogConditionMethods).GetMethod("HasDiagnosticCategory", BindingFlags.Static));

[304NotModified]

That's correct. It was skipped to make the change smaller. Also I was hoping if someone would request it :)

So feature request.

[snakefoot]

You can setup NLog-filtering using the WhenMethodFilter that takes a lambda-method:

https://github.com/NLog/NLog/wiki/Filtering-log-messages#fully-dynamic-filtering

[TheXenocide]

That might help people who have some particular set of logic they want to apply, but the nature of the original request is that we've made a library with various NLog extensions (renderers, layouts, conditions, etc.) as reusable tools that can be employed via configuration files (with the intention of being able to change them in production dynamically, at runtime), but to unit test them without making a bunch of configuration files requires using code-based configuration; in this case there is a newer more friendly way of registering some of those types of extensions, but for Conditions we still had to use the old way.

[snakefoot]

I like the idea of being able to specify "fullly qualified" type-names, and not just the symbolic-names. Has also been mentioned here #2944 for NLog-targets. But extending it to other NLog-building-blocks would seem natural.

The current model of using <extensions> is right now the current option for loading dynamically from config-file. Unless manually registering assemblies in code at runtime. If there are NLog-building-blocks that fail to register with <extensions> then it should be investigated.

You are always welcome to make PullRequests to improve in this area.

[snakefoot]

@TheXenocide Would this logic work out for you:

```c#
LogManager.Setup().SetupExtensions(s =>
s.RegisterConditionMethod("hasParameters", evt => evt.Parameters?.Length > 0)
);

```xml
<nlog>
   <targets>
      <target name='debug' type='Debug' layout='${message}' />
   </targets>
   <rules>
      <logger name='*' writeTo='debug'>
         <filters>
            <when condition='hasParameters()' action='Ignore' />
         </filters>
      </logger>
   </rules>
</nlog>

And ofcourse the usual suspect:

c# LogManager.Setup().SetupExtensions(s => s.RegisterConditionMethod("has-diag-category", typeof(NLogConditionMethods).GetMethod("HasDiagnosticCategory", BindingFlags.Static)) );

[snakefoot]

Created #3787 to resolve this in NLog 4.7

[snakefoot]

Resolved with #3787

[TheXenocide]

Apologies I didn't see this when you last asked, but the new syntax looks great. Thanks!