Support .NET Core

[natemcmaster]

It would be great to add support for using Antlr4 with .NET Core projects. There are 2 items here to truly support antlr on .NET Core:

(1) Antlr4 runtime. Ensure that runtime and generated code are compatible with .NET core apps. FWIW it appears the "netcore45" assembly in the nupkg already supports .NET Core. So this may be as simple as updating the packaging to install to the right TFMs.
(2) Antlr4 code-gen. Previously antlr4cs tied into MSBuild. Since .NET Core projects generally won't use MSBuild, it would be nice to add alternate ways of running antlr4 code gen. This could be done as a project tool for dotnet CLI. In theory this would be as simple as adding a simple command called dotnet-antlr that invokes java on the *.jar file with the right parameters.

[espenrl]

I did a brief analysis of Antlr4.Runtime compiled against .NET Core. See attached file for all compiler errors.

Ambiguous reference

• Antlr4.Runtime.Sharpen.ConcurrentDictionary
• Antlr4.Runtime.Sharpen.Tuple

Missing API

• Console class
• Thread class
• Serializable attribute

ICustomAttributeProvider missing -> use same impl. as PORTABLE

There are also some issues around reflection, but it is not a widespread problem.

Errors in Antlr4.vs2013.zip

[lecode-official]

I just checked out the repo, created a new .NET Core project for Antlr.Runtime, included the source code, and fixed all compiler errors. Now it properly compiles.

The ambiguous reference were resolved, by extending the conditional compilation to include a new define DOTNETCORE. This resolved the problem, because .NET Core already supports ConcurrentDictionary and Tuple.

The SerializableAttribute is missing, because .NET Core dropped support for binary serialization. Therefore, the attribute can just be removed (other serialization mechanisms do not depend on the attribute). I haven't, yet, dug into the code too deep, so I don't know if binary serialization is needed.

All the missing APIs concerning reflection (including that Type does not implement ICustomAttributeProvider) could be resolved, because those APIs have just been moved to the new type TypeInfo for performance reasons. The TypeInfo for a Type object can be retrieved by calling GetTypeInfo(), which is an extension method for the Type class.

There is just one problem left, because now the "old" project ("Antlr.Runtime.vs2013") does not build anymore. I think, that is because Visual Studio confuses the project.json from the other project, and tries to compile it using that. Therefore these two projects should be isolated by moving them into separate folders.

I am going to fork the repository and push my changes onto it. I would like you guys to review my changes and give me some feedback (or would you prefer if I created a pull request right away?)

[lecode-official]

I have now forked the repository, and pushed my commits. You can view the fork here: https://github.com/lecode-official/antlr4.

[ericvergnaud]

Hi,
Best is to submit a PR
Eric

Envoyé de mon iPhone

Le 7 juil. 2016 à 17:16, David Neumann notifications@github.com a écrit :

I just checked out the repo, created a new .NET Core project for Antlr.Runtime, included the source code, and fixed all compiler errors. Now it properly compiles.

The ambiguous reference were resolved, by extending the conditional compilation to include a new define DOTNETCORE. This resolved the problem, because .NET Core already supports ConcurrentDictionary and Tuple.

The SerializableAttribute is missing, because .NET Core dropped support for binary serialization. Therefore, the attribute can just be removed (other serialization mechanisms do not depend on the attribute). I haven't, yet, dug into the code too deep, so I don't know if binary serialization is needed.

All the missing APIs concerning reflection (including that Type does not implement ICustomAttributeProvider) could be resolved, because those APIs have just been moved to the new type TypeInfo for performance reasons. The TypeInfo for a Type object can be retrieved by calling GetTypeInfo(), which is an extension method for the Type class.

There is just one problem left, because now the "old" project ("Antlr.Runtime.vs2013") does not build anymore. I think, that is because Visual Studio confuses the project.json from the other project, and tries to compile it using that. Therefore these two projects should be isolated by moving them into separate folders.

I going to fork the repository and push my changes onto it. I would like you guys to review my changes and give me some feedback (or would you prefer if I created a pull request right away?)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[lextm]

As MSBuild is coming back to .NET Core, I think point 2 of @natemcmaster 's comment would be soon invalid. In my opinion, a better time to port ANTLR 4 to .NET Core should be some time when Microsoft officially finishes .NET Core/MSBuild integration, not now.

Anyway I will also check the PR associated #1229 to see if it meets my project's requirements.

[lextm]

I opened a new PR #1271 to show another approach to go to .NET Core/.NET Standard.

[TAGC]

Hey, I'm porting a project containing an ANTLR4 grammar from .NET Framework to .NET Core. For the .NET Core version of this project, I've referenced the latest prerelease version (v4.5.3.1-beta001) and it restores this successfully. However, I'm wondering if there's a way yet to do code-gen from the grammar file (i.e. @natemcmaster's second point). Or should I just copy the generated files from the obj folder of the .NET Framework version into the src folder of the .NET Core one for the time being?

[parrt]

we have merged in a dotnet update so closing this.