Read issue severity from issue element rather than issue type element if present

[bdach]

Hi,

I am a contributor on a few projects, where we use NVika for parsing InspectCode reports. Today, we've encountered a situation wherein bumping one inspection's severity level to warning would show them as warnings in Rider, but the NVika parsed output would show them as suggestions.

The immediate cause of that, it seems, is that we have both an .editorconfig file, as well as a .DotSettings file, which happened to have conflicting severity levels. InspectCode handles that by giving precedence to .editorconfig, as well as attaching a Severity attribute to the issue at hand (rather than the issue type):

The XML comprises two parts: (...)

• The list of found issues grouped by projects, where each issue has the following attributes: (...)
  • Severity — this attribute only appears if the severity of the issue differs from the severity of the corresponding inspection. This is possible if some projects within the solution have the 'Treat warnings as errors' option enabled and others do not - in this case some issues would have the 'Error' severity, which differs from the original 'Warning' severity.

(source for quotation)

This PR aims to follow that standard by reading and then giving precedence to the Severity attribute value if it is present on an <Issue> element, and only then falling back to the Severity read from the <IssueType> if the issue had no explicit severity.

---

I've attached a test case for this, but am unsure if it's packaged in the proper manner. Please advise if you would like to see adjustments to it. The code for the test is... a stretch, but I couldn't come up with a better illustrative example.

[laedit]

Thanks a lot for your contribution!
I am so sorry, I am pretty busy in the next few days and I think I will not be able to review it before next week.

[bdach]

Absolutely, I understand. No rush necessary, we can get by in the meantime.

[laedit]

Could you rename the file and class to something more meaningful, maybe like Convert?

[bdach]

Have renamed to Conversions, hopefully that's a bit more fitting.

(Incidentally, when updating references, I've had a bit of trouble with the parser assuming that line endings are always 1 character, which is not the case on Windows. This is probably not a huge issue because most git repositories are likely to be configured to core.autocrlf correctly, and also out of scope of this pull, but I figure I may as well bring it up.)

[laedit]

Thanks for the heads-up!

[laedit]

Thanks a lot for this fix!
I will try to release a new version before the end of the week.