After sending this PR, I've started writing tests. While everything I've tested on works correctly, I'm worried about const relation. Before this PR (when there was only one relation) it was simple: everything between the first and last bracket is the value to be stored for later use. Now, I've implemented custom language (there is even support for string literals, not pushed to remote for now), and it still doesn't guarantee that some complex const expression wouldn't confuse the parser. I have an idea how to solve the problem: reuse Roslyn. Wrap passed string in new[] { ... }, call ParseExpression and traverse C# syntax tree that is guaranteed to be completely correct.

@jkoritzinsky this PR is ready to be reviewed.

Note, that this PR enables new syntax: Length, Const and StructSize instead of the older variants. Older variants are still supported via string replacement, but that's obviously non-ideal. If const or struct-size occur in substring of relation arguments, they will be replaced too, but warning will be emitted (the least I can do).
The new syntax should be documented, but I would like to postpone the changes to the docs till later PRs (I expect more to come, the next one will be about value type marshalling and/or MSBuild SDK targets file refactoring).

Relatively unrelated question:
After some work on SharpGen, is the targets split (made in #20) necessary anymore? There is no more CodeGenApp. I think about batching these targets and tasks. That will remove mandatory serialization & deserialization (+ I/O) of large XML files on every build. This is also a blocker for moving from CastXML, potential Source Generators and Function Pointers proposal adoption.

Some of the tasks (the ones that discover which C++ files are inputs and which C# files are outputs) definitely need to stay separate. The rest of them could probably merge together. My goal with the separation was to enable generation to work incrementally, but the design of the config files breaks that.

@jkoritzinsky yep, I agree the tasks that compute inputs/outputs must stay separate.

My goal with the separation was to enable generation to work incrementally, but the design of the config files breaks that.

Could you please elaborate on that? I mean, I think it's because the config files specify inputs (source headers) MSBuild is not aware of, but I haven't given it much thought. What do you think is the cause of SharpGen regenerating everything almost on every build?

Meanwhile (waiting on this PR to be reviewed and merged), I'm having a look at #144. The patch there is insufficient (even SdkTests are failing, and for a good reason), I'm working on a better solution. upd: better solution implemented on my draft PR.

There are a few MSBuild tasks that the targets files use to enable discovering all of the input headers into SharpGenTools so that we re-run generation when only the native headers are changed and not require extraneous edits to the mapping files.

@jkoritzinsky it still doesn't explain why SharpGen 1.2 sometimes regenerates bindings for no good reason (observed numerous times, but I couldn't grab binlog since I was using Rider IDE). Meanwhile, I'm finishing my rework of SharpGen targets for v2:

1. Single task for running SharpGen, greatly simplified targets file
2. All outputs are now static. This means, among other things, that 5 generated .cs files contain code for all namespaces/config files, no subfolders for generated files.
3. Well-defined up-to-date checks behavior (with extensive documentation based on actual MSBuild sources)
4. Fixed missed regeneration when using undocumented <file /> config file inclusion method
5. Reimplemented documentation providers extensibility point from scratch to use Roslyn approach (like the one used for Analyzers/Source Generators, but based on implementing the interface instead of being marked with an attribute)
6. Reimplemented MSDN doc provider (MSDN retired, Microsoft Docs are used now), added tests
7. Dropped support for alternative SharpGen.Runtime assemblies, but improved WellKnownType overriding to compensate for that

This will take a couple more days, then I'll push it to draft PR branch. I hope this PR will be reviewed & merged by that time.

Rider’s usage of MSBuild is particularly poor since they try to do shortcuts. I wouldn’t be amazed if they broke things.

I’ll try to review this over the weekend so we can get it merged in.

Just a friendly reminder and an update on the following PRs.

1. Now there are only 3 tasks (SharpPatch, SharpGen and a new SharpGen-related task for a new property cache), solid target up-to-date checks behavior
2. All unit tests are now in a single project (fixes dotCover not showing the results properly in Rider and reduces test logger code duplication)
3. Extensions don't work now (extension assembly dependencies fail to load). This so obviously should work that I don't know why it doesn't, I feel like it's either a bug in AssemblyLoadContext, or myself, probably the latter. I'll fix that, of course, but today was a disappointing day.
4. SharpGenTools.Sdk is now an actual MSBuild SDK, removes the need to remember to specify PrivateAssets attribute on a PackageReference
5. SharpGen.Runtime is now implicitly referenced (always correct matching version)
6. Filed/hit some NuGet and MSBuild issues. Nothing critical, but one issue was somewhat annoying.

That work sounds fantastic! I’ve merged this PR in in the meantime so we can keep moving forward.