@hez2010 first of all thanks for the contribution.

Question: do we need to change something in the NuGet package generation?

I'm just wondering just for clarity when reading the code, if we can set the attribute DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.All) in each class itself (GrammarDefinition, Repository, Contributes, etc ... ) instead of defining the KeepType in the InitializeAvailableGrammars.

What do you think?

I'm just wondering just for clarity when reading the code, if we can set the attribute DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.All) in each class itself (GrammarDefinition, Repository, Contributes, etc ... ) instead of defining the KeepType in the InitializeAvailableGrammars.

What do you think?

Unfortunately, DynamicallyAccessedMembers doesn't work in that way.

Sorry I'm getting this in the demo application when testing you PR :-\ Not sure what's wrong.

Sorry I'm getting this in the demo application when testing you PR :-\ Not sure what's wrong.

It seems that you are running as a x86 process? I changed the default architecture to x64 on Windows, so on x86 the onigwrap.dll won't be copied to the artifact directory in the development environment.

Also, it seems that the tests in the CI pipeline are hanging due to the x68/x64 issue.

Now all passed green!

Well I'm running "Debug" and "Any CPU" environments, but it seems that VS wants x86 not sure why, let's keep this for compatibility since x86 is compatible with both but the other way around ;-)

Unfortunately, DynamicallyAccessedMembers doesn't work in that way.

No worries, we can leave it as it.

To test NativeAOT, you can change the demo project to net7.0 and use dotnet publish -c Release -r win-x64 /p:PublishAot=true. Note that by default the x86 onigwrap.dll will be copied to the publish directory and results in architecture mismatch, you need to copy the x64 onigwrap.dll to the publish directory manually. (This only happens in the development environment and won't affect the published nuget package).

But I'm thinking that maybe we can reimplement the searcher using built-in Regex instead of oniguruma in the future?

But I'm thinking that maybe we can reimplement the searcher using built-in Regex instead of oniguruma in the future?

It would be great to have 100% managed code and get rid of native deps!

I'm not sure how hard it would be. Currently, grammar definition files (which have been taken from Visual Studio code) talk Oniguruma dialect, so I don't know how hard would be to write a mechanism that converts those regexes to something understandable by C# built-in regex syntax.