changing project properties to make them fit better

[nblog]

1. Replace with a reference to the "bson" project.
2. Remove "libyara", provided by nuget (https://www.nuget.org/packages/Microsoft.O365.Security.Native.Libyara/)
3. switch "bson" and "loader" projects to v141_xp(Part of the configuration is v141_xp, but it's messy)

[kevoreilly]

Thank you for the pull request. The idea to switch to nuget libyara is interesting - what motivated you to do this? Unfortunately their build is 9 months old so it's too outdated to replace the manually built one I'm afraid.

[nblog]

This repository is sourced from Microsoft and is guaranteed upstream, both in terms of usability and stability.

Another main reason is that the linking method uses lib\libyaraXX.lib, which can lead to inconsistencies between the version of the runtime library and the yara-lib runtime library due to different versions of VS.

[kevoreilly]

That sounds great - by guaranteed upstream you mean it is the latest release (4.5.0) or even the latest commit to master?

I'm concerned that on the NuGet Gallery page it states Last updated 9 months ago

[nblog]

It comes from https://github.com/Microsoft/libyara.NET and it doesn't seem that Microsoft has updated it, maybe I'm trusting Microsoft too much😂, but to solve the runtime library conflict problem, I could modify it to reference libyara in source form, depending on which way you want to accept it?

[kevoreilly]

I'm not sure I follow - what runtime library conflict?

[nblog]

The compiled lib\libyara64.lib is bound by the C run-time library (CRT) and (/MD or /MDd) or (/MT or /MTd), which prevents arbitrary switching.

[kevoreilly]

Arbitrary switching?! What is that and why would the project benefit?

If it is intended for convenience to switch to an unsupported compiler, then unfortunately it's not an issue which needs fixing. The project focuses strongly on detonation quality which is demonstrably weakened by other compilers e.g. #61

[nblog]

This is indeed a problem, we can wait for the problem to be solved before tweaking it, leaving it in the open for now might help with issues like #71 .

[kevoreilly]

There exists a problem with using VS2022, hence why this compiler is not supported. However this is not a capemon issue, so it's not an issue for this project.

The important point here is detonation quality is the only criterion for a valid issue, and there are currenrly no plans for VS2022 ever being supported.