-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is the target compatible with the new NLog extension configuration? #307
Comments
Looks like I was not thorough enough, when adding support for embedded assembly-name in type-alias. I liked the dotnet-syntax of specifying the assembly-name. But seems it is not compatible with QName-format. Maybe adding support for assembly-name as QName-prefix like this: <target xsi:type="NLog.Targets.Syslog:Syslog" name="cee-udp"> See also: NLog/NLog#4979 |
Curious is the XML Schema validation is still able to validate properties for the SysLog-target when using |
@davidgeary In your example you use |
Maybe it comes from these examples: https://github.com/luigiberrettini/NLog.Targets.Syslog/blob/master/src/TestAppWithTUI/NLog.config Curious what is expected from |
The precise reason is lost in the mists of time, but best guess is that I just copied it from an example somewhere :-) I've just tried replacing AFAICS, the only place they mention the new capability of including the assembly name is in the list of NLog 5.0 changes:
This would suggest that the assembly must follow the type, separated by a comma. (Was about to suggest getting clarification from NLog, but have just seen the issue you've raised, so will add a comment to that.) |
Thank you for confirming that intellisense also works for you when using prefix Now just need to decide if it should be NLog 5.0.2 or NLog 5.1 for using |
The |
Closing since the misbehavior is not caused by the target. |
Pretty sure the QName-prefix is optional. |
Yes, like for attribute names. |
Yes currently NLog puts a lot of effort into stripping away the prefix, so was just curious what benefit the prefix had. Was maybe thinking to support this format |
But this issue wasn't about the target specifically; it was to do with the XML schema, which identifies the new format as invalid. (The original title of this issue was "XML schema warning issued when specifying extension assembly via target's type property".) The warning incorrectly gives the impression that including the assembly name in the |
The The problem is not the XML-schema, but the NLog-team having broken the XSD-xsi-standard, by introducing a non-standard format which doesn't work with the Guess we need more space-cowboys from the 2000's that knows XML / XSD / XSLT by heart on the NLog-team, but until that happens, then we just have to go along with what we have, and repair as we go. See also NLog/NLog#4979 |
It seems from Wikipedia that the QName syntax is An NCName value follows these rules:
This means that NLog should support one of the two options below, where OPTION 1 <?xml version="1.0" encoding="utf-8"?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:sl="http://www.nlog-project.org/schemas/NLog.Targets.Syslog.xsd">
<extensions>
<add assembly="NLog.Targets.Syslog"/>
</extensions>
<targets>
<target xsi:type="sl:Syslog" name="syslog-tgt">
<!-- ... -->
</target>
</targets>
<!-- ... -->
</nlog> OPTION 2 <?xml version="1.0" encoding="utf-8"?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:sl="http://www.nlog-project.org/schemas/NLog.Targets.Syslog.xsd">
<targets>
<target xsi:type="sl:Syslog_NLog.Targets.Syslog" name="syslog-tgt">
<!-- ... -->
</target>
</targets>
<!-- ... -->
</nlog> |
@luigiberrettini Any reason why |
Because prefix should be an XML namespace declared in the file like In my opinion the goal should be both complying with specs and avoiding validation warnings/errors. |
When using But with |
Ok then we need to find something that respects the specs and can be validated with a proper XML validator and then see if the Visual Studio validator works properly. |
What about |
As I said that does not respects the specs. Having as a goal to remove warnings will result in somebody else opening an issue because it is not XML compliant and not solving both is just saying, use another option, in which case this could have been the reply to this issue also. |
How does the QName-prefix |
As I wrote above the prefix must be an XML namespace and it is not. I found out that |
The best solution would be to use the power of XML adding an <?xml version="1.0" encoding="utf-8"?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:sl="http://www.nlog-project.org/schemas/NLog.Targets.Syslog.xsd">
<targets>
<target xsi:type="sl:Syslog" assembly="NLog.Targets.Syslog" name="syslog-tgt">
<!-- ... -->
</target>
</targets>
<!-- ... -->
</nlog> |
|
I do not know if it is reserved, to me you can use whatever word you prefer: you just need to add it in the NLog XSD specification so that it is recognized as attribute of the |
Yes that is also a possible way for making assembly-loading-hint work with xsi:type-attribute without validation-errors. Though I prefer |
The important thing is just to declare it in the docs, then you can even diverge a lot more from the standard. |
Still I believe that a separate attribute in the XSD Target abstract complex type would be cleaner, more efficient than splitting for parsing purposes and could allow to deprecate the extensions altogether. |
Can now see that my initial idea was a little better ( |
One not so nice solution but working and complying with specs: <?xml version="1.0" encoding="utf-8"?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:NLog.Targets.Syslog="http://www.nlog-project.org/schemas/NLog.Targets.Syslog.xsd">
<targets>
<target xsi:type="NLog.Targets.Syslog:Syslog" name="syslog-tgt">
<NLog.Targets.Syslog:layout xsi:type="SimpleLayout" text="${message}" />
<!-- ... -->
</target>
</targets>
<!-- ... -->
</nlog> |
Considering that you want to support both extensions plus target name and no extensions plus assembly plus target name there is no solution working since target XSDs only have one or the other. I have Syslog in mine and any change would imply me changing the name in the XSD, making the XSD NuGet package useless unless you force all target implementers to always use the full name. |
The idea was not to force anything, but just to make it easier to provide an assembly-loading-hint with the type-alias. But see that you have to navigate careful in the woods of XML and xmlns. Guess @davidgeary should stay away from using Alternative replace |
Bug description
Using the latest version of NLog (5.x), extension assemblies must now be explicitly specified, either via the
<extensions>
element or by suffixing thetype
property of the<target>
element, as described in PR 295.However, when the
type
property is suffixed with the assembly name, a schema warning is displayed in Visual Studio.Note that the warning does not prevent compilation (unless your project has
Treat warnings as errors
set totrue
). Regardless, a workaround is to specify the assembly in the<extensions>
element instead, rather than in the target's type.Expected behavior
No warning to be displayed.
Actual behavior
A schema warning is displayed:
Visual Studio screenshot:
To reproduce
<extensions>
element<target>
element opening tag from:to
Additional context
The text was updated successfully, but these errors were encountered: