This is typically done with nuget packages in .NET, working with that ecosystem is probably the best step up from referencing projects directly, with the benefit that you can update your library without breaking your existing code that uses it via version pinning.
Option 2 is better and there are objective reason for this. And yes, the approach can be improved.
More details: why option 2 is to be preferred
Option 1 lacks separation of concerns. What does this mean?
Imagine that one day your project could afford to hire a team, with an expert of serialization, another specialist for iteration, and a guru ...
Is it just a matter of personal preference or is there a reason why to choose one solution over the other ? (or a completely different approach).
No, that's not a matter of personal preference.
It's always better to have the several components being implemented in separate header files (as you suggest for your 2nd solution).
This will increase
Your suggestions for true and false make them unsuitable for use in #if preprocessing macros, something that the language standard specifically mentions.
One reason to not have bool built in is the volume of existing code that defines a bool type or macro. Having bool be a built-in type would break this existing code.
Yes, this is a version of command query separation where your DAL implements the separation of the commands and queries.
Refactor your DAL to take two connection strings and run the commands against the updatable DB and the Queries against the read only db.
In practice I'm not sure how much of an improvement you will see. If you are only doing a few ...